+1 Denis. I cannot understand why OAuth is used in this user (or many others in development) as there is no authorization involved!
The verifier asks the user (wallet) for data (perhaps with some back and forth) the user (wallet) supplies the data or not with consent to the conditions supplied by the verifier.There is no separate RO or authorization path. Starting with OAuth in these cases adds a level of complexity that is wholly unnecessary. ..tom On Sat, Sep 9, 2023 at 6:44 AM Denis <denis.i...@free.fr> wrote: > 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> 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 >> https://www.ietf.org/mailman/listinfo/oauth >> > > > -- > > > ORIE STEELE Chief Technology Officer www.transmute.industries > > <https://transmute.industries> > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
