- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Tue, 14 Jun 2016 09:50:00 -0400
- To: public-credentials@w3.org
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 -- Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) Founder/CEO - Digital Bazaar, Inc. blog: The Web Browser API Incubation Anti-Pattern http://manu.sporny.org/2016/browser-api-incubation-antipattern/
Received on Tuesday, 14 June 2016 13:50:28 UTC