Hi Denis, OAuth defines 4 roles, see Section 1.1 of RFC 6749. In the three party model there is likely a human behind the holder as well.
You can map the OAuth terms to the VC terms, if you like, as follows: * Issuer: Authorization Server * Holder: Client * Verifier: Relying Party TEEs, Trusted Applications, etc. are implementation specific details. You can use them in OAuth, and other protocols as well. Regarding the question: "What the IETF should do (or not do) in this area ?" The answer is: We are working in the IETF on these topics already, see Web Authorization Protocol (oauth) (ietf.org)<https://datatracker.ietf.org/wg/oauth/documents/>. Regading the question: "The protocols between an holder and a verifier are rather different from those defined din OAuth, since in many cases they support Zero-Knowledge proofs (ZKPs). The answer is: No,not necessarily. That's what the whole SD-JWT is about. Ciao Hannes Von: OAuth <oauth-boun...@ietf.org> Im Auftrag von Denis Gesendet: Samstag, 9. September 2023 15:44 An: Roman Danyliw <r...@cert.org> Cc: oauth <oauth@ietf.org> Betreff: Re: [OAUTH-WG] OAuth and JWT/VC documents Historically, the OAuth WG has been using a model including five components: the user, the Client, the AS, the RO and the RS. The model applicable in the context of the "three part model (issuer, holder, verifier)" is rather different since there is no AS, nor RO. An AS should not be confused with an Issuer. An Issuer has no relationship with a verifier. In the "three part model", a Credential is issued by an Issuer to an holder who may then derive himself from it one or more Verifiable Presentations without any call-back to the Issuer. The holder may then present to a RS one or more Verifiable Presentations derived from Credentials issued by the same or different Issuers. It is implicit that the "three part model" shall support selective disclosure of the holder's attributes. The "three part model (issuer, holder, verifier)" involves more entities / components: the user, the TEE (Trusted Execution Environment) supported by the smart phone or tablet manufacturer, Trusted Applications (TAs) placed into the TEE, the providers of these Trusted Applications (TAs) and the RichOS supported by the smart phone or tablet. Security and privacy concerns can only be achieved while considering the whole chain. The protocols between an holder and a verifier are rather different from those defined din OAuth, since in many cases they support Zero-Knowledge proofs (ZKPs). Before designing an architecture, it is important to raise the following questions: * Is it desirable to support linkability between verifiers and/or unlinkability between verifiers ? * How to bind a Verifiable Presentation to its legitimate holder while also supporting the unlinkability property between verifiers ? IMO, bridging the architectural narrative used in the core OAuth framework (AS, RS, RO) and three part model (issuer, holder, verifier) is not desirable. This would add confusion. Extending the OAuth charter to address the "three part model" is not desirable. Some committees and foundations are already addressing this topic, e.g., W3C, OpenID, DIF (Decentralized Identity Foundation) and GlobalPlatform (for the TEE). The key question is: what the IETF should do (or not do) in this area ? A BoF should be opened to continue this discussion. Denis Thanks for kicking off the conversation! Inline: On Fri, Sep 8, 2023 at 2:08 PM Roman Danyliw <r...@cert.org<mailto:r...@cert.org>> wrote: Hi! We've observed growing energy around JWT, selective disclosure and VC related topics in the WG in recent meetings. We spent almost all of the third OAuth meeting at IETF 117 on related topics. The initial SD-JWT (draft-ietf-oauth-selective-disclosure-jwt) has been followed up with SD-JWT-VC (draft-ietf-oauth-sd-jwt-vc). There is also work like draft-looker-oauth-jwt-cwt-status-list being proposed. As promised at IETF 117, we would like to start a conversation about the direction the WG would like to take at a strategic level rather than continuing to deal this topic in one document increments of additional scope. ** What's the body of work around SD/JWT/VC that should be done and how much work will that be? What needs to be done first? What unknown about the direction and needed tasks? There are building blocks that "look like VC" but are actually vanilla JWT / relevant outside the 3 party model. I would recommend keeping them at OAuth (status list cwt is an example of this IMO). It's possible that a document at OAuth recognizing the data model elements of the 3 party model (iss, sub, cnf, kid, etc) might help enable documents outside of OAuth to better defer to OAuth for "moving tokens, or leveraging successful protocols"... this could help reduce the data model reinvention everywhere else, and it could drive the common understanding of registered claim names to be interpreted consistently across JWT / CWT (and their SD friends). ** For whatever that work might be, how should the OAuth charter evolve to support the work? I don't know, but I am happy to help : ) One thing that seems worth unpacking is why DCP at OIDF is leaving the OIDC part behind (paraphrasing, kristina probably has a better take): https://openid.net/wg/digital-credentials-protocols/ Are there things DCP might need from OAuth WG, how might the charter align to that work? ** Is there work to be done around bridging the architectural narrative used in the core OAuth framework/RFC6749 (AS, RS, RO) and three part model (issuer, holder, verifier) used in draft-ietf-oauth-selective-disclosure-jwt? I think so? but it depends on the comment above. Personally I would like to see the OAuth WG tackle this head on, especially because of the wallet / client / subject / holder confusion.... Starting with the people we are here to serve seems like a safe way to progress through the technical sugar (which I love). OS Thanks, Roman, Hannes, and Rifaat _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth -- ORIE STEELE Chief Technology Officer www.transmute.industries<http://www.transmute.industries/> [cid:image002.png@01D9E585.81B6EB40]<https://transmute.industries/> _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
