Re: Review of "Use Cases and Requirements for Decentralized Identifiers"

Oskar,

thank you. I am sure these will have to be discussed.

However, on a purely practical level: this group works almost exclusively via github. I think it would be very helpful, if you could translate the various remarks into issues in [1]. It makes it easier for both the editors and the group to follow and, possibly, answer to the remarks…

Thank you, and see you in about a week!

Ivan


[1] https://github.com/w3c/did-use-cases


----
Ivan Herman, W3C
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
ORCID ID: https://orcid.org/0000-0003-0782-2704
On 20 Jan 2020, 16:56 +0100, Deventer, M.O. (Oskar) van <oskar.vandeventer@tno.nl>, wrote:
> Dear colleagues of the W3C-DID-WG,
>
> This is my first post on the W3C-DID-WG email list. I work for TNO, which is a 2700-employee Dutch national research institute. I am part of a 10-person research group focusing on self-sovereign identity, and especially on the link with the business layer. We are aiming to replace cumbersome manual paper checking by “administration factories” (government, insurers, pension funds, …) with much faster and cheaper SSI-based electronic checks. I have been modestly contributing to Hyperledger Aries on DIDcomm and Peer DID. I shall participate in the W3C-DID-WG meeting in Amsterdam next week.
>
> Please find my review of “Use Cases and Requirements for Decentralized Identifiers” below. Please let me know if you think this review is useful, and/or requires further discussion.
> (I may be commenting on things that have already been asked-and-answered in the past.)
>
> Thank you.
>
> Oskar
>
> Review of http://www.w3.org/TR/did-use-cases/
> “Use Cases and Requirements for Decentralized Identifiers, W3C Working Draft 04 December 2019”
> By Oskar van Deventer, January 20, 2020
>
> Comment 1: It is unclear what is identified by a DID.
> “DID subject: the entity identified by the DID and described by the DID document”. What a DID document provides is a bunch of public keys and service end points. It does not describe an entity. I would expect a description of an entity in terms of attributes, claims and verifiable credentials, which is out of scope of DID, I presume.
>
> Comment 2: There is no distinction between electronics and humans/organisations
> Electronic signatures are typically placed by a piece of electronics, as humans do not perform elliptic-curve crypto calculations by hand. I suggest a strict distinction between “electronic agent” and “party”, the former just executing code and the latter being a legal and/or natural entity that has its own business rules, and that may respect the rules of some other parties.
>
> Comment 3: It is unclear what “control-on-behalf” means.
> “... the Controller is said to be taking action on behalf of the Subject” does not make clear what the consent situation is, and it may be read as impersonation. Moreover, representation, mandating, delegation, guardianship and the like are very jurisdiction-specific, and should perhaps better be modelled with verifiable credentials, and not in the DID layer
>
> Comment 4: DID only supports “eIDAS -low”
> Proving control over a DID provides only a low level of assurance. This “eIDAS low” may be insufficient for cited use cases with high stakes (e.g. Enterprise, Digital Executor, regulated prescriptions). The document should make this  clear.
>
> Comment 5: What are typical authentication requirements by the relying party?
> For example: buying or selling a house. Do I as relying party sufficiently trust that ...
>
> • ... the DID Controller is actually the owner of buyer of the house?
>
>
> • ... or that the DID Controller represents that party?
>
>
> • ... the electronic agent that performed the public key signatures technically does actually represent that party?
>
>
> • ... the electronic agent of the counterparty was not compromised at the time that the electronic signature was placed?
> • ...  the hardware that runs the electronic agent was not compromised at the time that the electronic signature was placed?
> • ...  the hardware has correctly performed any PIN and/or biometric checks?
>
> I wonder whether/how verifiable credentials may help in achieving this additional trust, and getting to higher eIDAS levels. This may require further study, as well as coordination between W3C DID WG and W3C CCG WG.
>
> Comment 6: Why pseudonymous biometrics in a DID document and what does that mean?
> According to the terminology section, a DID document may contain pseudonymous biometrics.
>
> • Aren’t biometrics an attribute of a subject, and hence shouldn’t such belong to the verifiable credentials layer? Ditto for other attributes or claims describing the subject? Moreover, who is the signatory for those attributes and claims? To put it otherwise, why should one want to put verifiable credentials (self-attested or not) into a DID Document?
> • When pseudonymous biometrics are included, then what are the associated proof methods? Also shouldn’t there be a verification method specified? And a Party that performs this verification?
>
> A simple solution may be to remove any reference to biometrics from the definition of DID document.
>
>
>
> Dr. ir. M.O. (Oskar) van Deventer
> Senior Scientist Blockchain Networking
> Dept. Networks
> T +31 (0)88 866 70 78
> M +31 (0)65 191 49 18
> E oskar.vandeventer@tno.nl
> Location
>
>
> This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.
>
> TNO Blockchainlab: https://blockchain.tno.nl
>
>
>
>
>
>
>