Re: public key in a verifiable credential

For what it's worth, there is no "Bob" in my scenario. By client I mean an OAuth 2.0 client endpoint. The only thing a resource server/validator should see is a public key included in a token/vc singed by the authorization server/issuer. 

Best,
Nikos

--
Nikos Fotiou - http://pages.cs.aueb.gr/~fotiou
Researcher - Mobile Multimedia Laboratory
Athens University of Economics and Business
https://mm.aueb.gr

> On 1 Apr 2021, at 8:26 PM, Alan Karp <alanhkarp@gmail.com> wrote:
> 
> I'm glad to hear that.  My comment was about being careful of the way we explain things, because of some bad experiences I've had when I was sloppy in my wording.  When you say "Bob's public key," many people take that to mean a well-known key validated by some certificate authority.  I have encountered less confusion when saying, "A public key provided by Bob" or even better "A public key provided by Bob for this purpose."  There's still sometimes confusion, just less frequently.
> 
> --------------
> Alan Karp
> 
> 
> On Thu, Apr 1, 2021 at 10:10 AM David Chadwick <D.W.Chadwick@kent.ac.uk> wrote:
> 
> 
> On 01/04/2021 17:23, Alan Karp wrote:
>> On Thu, Apr 1, 2021 at 9:09 AM David Chadwick <D.W.Chadwick@kent.ac.uk> wrote:
>> By  Oauth "client" key you actually mean the subject's (in VC terminology) public key. Thus the subject ID is the natural place to put this. Using a DID as the subject's ID is either a direct or indirect way of referencing the subject's public key. So all VCs do this. 
>> 
>> 
>> There are many reasons why you would like an authorization certificate to be issued to a one-off public key.  Using the term "client key" doesn't preclude that but does get people thinking you are referring to the client's one and only key.  The same applies to using a DID.  You can create a DID on the fly, but most people don't think that way.
> Indeed, and this is exactly what our VC systems does :-)
> 
> Kind regards
> 
> David
> 
>> 
>> --------------
>> Alan Karp