The problem is that we need a 2 party, off-line model for the world of mobile devices. that should not depend on OAuth.
..tom On Mon, Sep 11, 2023 at 8:22 AM Orie Steele <orie@transmute.industries> wrote: > As far as I know, OpenID and DIF both use OAuth for these cases (the 3 > party model). > > W3C focuses only on the data model (in JSON-LD and RDF).... and lacks > the expertise to focus on the other parts (including security, and > transport considerations IMO.) > > GlobalPlatform and others are related to the area by the concept of > attestation, which is related to gaining higher confidence in the OAuth > roles (Client, Resource Server, wallet / credential issuer, etc...) > > Regarding a BoF for this topic, as opposed to extending the OAuth charter, > you might be interested in: https://mailarchive.ietf.org/arch/browse/spice > > Regardless of where the "3 party model" lands at IETF, I think there > should be coordination with JOSE, COSE, OAUTH, given their existing use in > this ecosystem... > > But that does not necessarily mean charter changes for OAuth, it could be > as simple as cross posting and seeking review where it makes sense to do so. > > Maybe a different way of gaining clarity on the same topic... If OAUTH > were to recharter, what would it include / exclude... (ignoring the 3 party > model for a second)... would attestaton be in scope? > > Regards, > > OS > > > On Sat, Sep 9, 2023 at 12:57 PM Tom Jones <thomasclinganjo...@gmail.com> > wrote: > >> +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 >> > > > -- > > > ORIE STEELE > Chief Technology Officer > www.transmute.industries > > <https://transmute.industries> >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
