Re: Proof of possession

And if I do not want to register a subject ID, can I simply use my
public key as my subject ID and submit the same string twice?

regards

David



On 14/06/2016 14:50, Manu Sporny wrote:
> On 06/14/2016 03:13 AM, David Chadwick wrote:
>> Having read the latest architecture document
>>
>> http://w3c.github.io/webpayments-ig/VCTF/architecture/v4/
>>
>> I note that there is no explicit mention of proof of possession
>> (PoP).
> 
> PoP is an implementation detail based on the "Subject Identifier" and
> the contents of the "Digital Signature of Issuer":
> 
> http://w3c.github.io/webpayments-ig/VCTF/architecture/v4/#verifiable-claim
> 
> We have tried very hard to not inject implementation details into the
> architecture diagram. Implementation details are what the Verifiable
> Claims Working Group are supposed to determine.
> 
>> Is this because the group has not discussed this topic, or has
>> already decided to recommend or prohibit the use of
>>
>> bearer tokens, public keys of subjects, or subject identifiers
> 
> None of those have been "prohibited from use" in phase I of the
> Verifiable Claims Working Group charter work. Phase I is about
> establishing a data model and set of syntaxes for expressing verifiable
> claims.
> 
> One deployment may choose bearer tokens (for the purposes of
> implementation ease or pseudo-anonymity), another may use public keys of
> subjects (if Subject and Holder are the same), another may use public
> keys of holders (if Subject and Holder are different).
> 
>> I tend to get the impression that subject identifiers seem to be the 
>> implicit way of providing PoP. Is this correct?
> 
> Yes, more or less. This is what an entry in the Identifier Registry
> looks like today:
> 
> https://authorization.io/dids/did:76d0cdb7-9c75-4be5-8e5a-e2d7a35ce907
> 
> "id" is the Subject Identifier
> "publicKey" is the Subject Identifier's public key
> 
> One way the registry could be implemented in the long term is storing
> this information in a Kademlia+ hardened DHT with a
> Blockchain/Generalized Ledger storing the history for each Subject
> Identifier. Note that I said ONE way that it could be implemented, there
> are many - each with their benefits and drawbacks.
> 
> Also note that this is an implementation detail and we don't need to
> solve this problem for the Phase I work. It's discussed in the
> architecture so that folks have a better idea of the type of system that
> we're trying to build.
> 
> -- manu
>

Received on Tuesday, 14 June 2016 14:34:25 UTC