Perfect properties of plastic cards 1. Unforgeable 2. Personal, cannot be used by anyone other than the owner or his delegate 3. Any recipient can validate its authenticity. 4. User consents to its use every time. 5. SP has a policy about what cards it accepts and this is relayed to the user in an understandable way 7. Instantly revocable 8. Cheap to produce 9. Bring clear business benefits to the issuer and acceptor 10. Are very easy to use by users and give them benefits 11. Limit the losses of all parties in cases of abuse, ideally to zero 12. Its not so much an issue of where the credentials are used that is a problem, its more like 'is the user the rightful owner of them'. Brad Hill said it is hard to control where users are allowed to send them. This is the wrong perspective. Users should be able to send them anywhere without any controls being placed on them by the credential issuer. After all, the credentials are the PII of the user. The only control should come from the RP, specifically, will the RP accept them or not. All the RP needs to know is, i) is the credential valid/authentic and ii) is the presenter the rightful owner of them ie. they should NOT be bearer credentials as in todays SAML systems. Why does this problem exist today? There are many reasons for this, but perhaps they can be condensed to "No standard user friendly system exists that both AAs and SPs are willing to implement" If you ask Why is this, the reasons are legion, such as: i) what are the business benefits for AAs participating, that justify the costs of implementation ii) what are the business benefits for SPs participating, that justify the costs of implementation iii) some of the privacy, security and usability issues are contradictory and negate each other e.g. providing high user privacy can prevent SPs from gaining recompense in cases of abuse, insisting upon strong user authentication can inhibit usability, Should verifiable claims be service-centric (like OpenID Connect), or should they be user-centric (Credentials CG demo)? They should be User centric without doubt. Should there be a standard way of expressing verifiable claims (e.g. educational transcripts, professional licenses, KYC information, government IDs, etc.)? Yes. Since the same claims can be used in many different context. How are verifiable claims issued to entities? By entities asking issuers for them, similar to the way I ask for plastic cards today. This can be pre-transactional or mid-transaction (on demand). Both modes operate effectively today with plastic cards. I apply for a VISA card before I undertake transactions, whilst I apply for a supermarket discount card at the checkout. Where are verifiable claims stored? It does not matter. The user should be able to choose. If they have the relevant security properties e.g. cannot be forged, cannot be misappropriated, cannot be misused, cannot be stolen and used by the thief, are confidential etc. then they can be stored anywhere. How does an entity request verifiable claims from another entity? Via its authorisation policy. The policy states the alternative sets of credentials that are acceptable to it. How are verifiable claims revoked by the issuer? If they are short lived, they don't need to be. If they are long lived, then one of the existing revocation schemes can be employed. Does the web browser have a role to play in this ecosystem (via native browser APIs)? Yes, since the majority of web transactions involve the use of browsers. But mobile apps should be just as capable of playing the same role as browsers. This indicates that the browser role should be minimal, and primarily as a vehicle for passing messages from one entity to another. How are verifiable claims moved from one storage provider to the next? They should be copyable as files, just like pictures, text docs or anything else. What are the privacy concerns and implications of the known architectures? There should be no globally unique IDs. Users should have complete consent and control over the credentials that are released, at a very fine granularity of consent ie. per attribute control. SPs should request the minimum credentials that are necessary for the current transaction. IDPs should not know where users use their credentials, unless users want them to. SPs should be able to dynamically change the credentials that are required as users undertake different actions. It should not be 'grab everything up front at authentication time, regardless of what the user may or may not eventually do' Are portable identifiers a part of the solution? Are service-centric identifiers a problem (if so, what about them are problematic)? An identifier is simply another attribute that has the special property of uniquely identifying a user. Since the user centric credentials are portable, then so are credentials that contain identifiers. I do not see them as anything special in this respect. Service-centric IDs are good from a privacy preserving perspective. But they are a problem to work with when you want to link a user's activities between sites e.g. for a global audit trail, or for delegating permissions between services etc. Is W3C the right place to do this work? Does it have the right people and skillset to succeed? It is interesting that FIDO has handed its specs over to W3C. Why did it do this?