Hi, I'm fashinated by these interpretation processes. It sounds resonable having mapped the OAuth roles in three types:
Issuer or AS Holder or Client Verifier or RP even if we try to keep things simple the real world continuosly breaks the plans (as in the society the genders ...). We often forget the User, that sometimes assumes the role of the "resource owner"; and not at least the TTP, the trusted third party, whatever it express in our minds, since trust still seems an abstract, or controversial, strategy, more sociological than ... Look, It Is everywhere but still on the edge of the OAuth literature! Anyway the challenge doesn't stop here, since in the Wallet ecosystem the roles ends with swapping and mixing up, depending by the context, eg: The holder became an AS during the presentation phase. As in the biological, economics and sociological sciences, the diversity is still the most important feature that allows a system to evolve, I believe that the OAuth2 ecosystem with its solid roots Is the best place where this diversity can be welcome. This Is also for the future of OAuth2 I believe. I agree all the concerns about how the things are getting inflated and the entropy increased losing the quality: everybody knows. There might be the plan, or the vision, to merge some drafts together to give the baseline for a complete architecture with well defined and harmonized roles and features? Il sab 9 set 2023, 15:44 Denis <denis.i...@free.fr> ha scritto: > 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
