I was following your train of thought, let me paste that here for transparency, you specifically said:
> In an OAuth scenario, the user‘s wallet would act as AS and issue access > tokens (those could be short lived) that effectively are verifiable > presentations (based on a verifiable credential) audience restricted for a > certain RS. The client wouldn’t even know it’s a verifiable presentation > since the access token is opaque to the client. Which I replied: > If the user's wallet acts as the AS issuing tokens, then there is zero > need for this draft because we could pass the *scopes* that relate to the > claims directly to the AS, and have the AS return a limited JWT, and we > would actually do that every time because: > > 1. we can > 2. because the tokens have short lifetime > > So that isn't a valid argument, unless there's a reason why the AS > wouldn't be able to do this. In this conversation, I'm still not able to parse what you are saying. Yes, of course the user having a physical device (as the AS) to issue tokens is privacy enhancing, but then we don't need this draft as I just proved. Or are you talking about a different point? On Tue, Aug 2, 2022 at 10:54 AM Torsten Lodderstedt <torsten= 40lodderstedt....@dmarc.ietf.org> wrote: > > > Am 02.08.2022 um 10:48 schrieb Warren Parad <wparad= > 40rhosys...@dmarc.ietf.org>: > > > Can you please reread what you wrote and rephrase it differently? Telling > us to look at the OAuth JWT RFC isn't helpful here. > > > You say the AS can issue an access token every time and I say the wallet > can issue access tokens on its own without the need to go back to the AS > every time again. That’s privacy enhancing and helps scalability. > > Also it isn't clear which part of your statement you are trying to > clarify. What does "original AS" mean? Are you suggesting a "multi AS" > configuration? What does that look like? > > On Tue, Aug 2, 2022 at 10:44 AM Torsten Lodderstedt <torsten= > 40lodderstedt....@dmarc.ietf.org> wrote: > >> >> >> Am 02.08.2022 um 10:35 schrieb Warren Parad <wparad= >> 40rhosys...@dmarc.ietf.org>: >> >> >> Why would we not include those seemingly critical details in the draft >> then? >> >> 1. Let's define what a *verifiable presentation *is (is that already >> defined somewhere? I didn't see it in the draft) >> 2. Require the JWTs to be signed with a private key from a >> certificate chain, and include the whole certificate chain in the body. (I >> don't think there is already a RFC for this, but I could be wrong) >> >> Let's also talk about this comment: >> >>> In an OAuth scenario, the user‘s wallet would act as AS and issue access >>> tokens (those could be short lived) that effectively are verifiable >>> presentations (based on a verifiable credential) audience restricted for a >>> certain RS. The client wouldn’t even know it’s a verifiable presentation >>> since the access token is opaque to the client. >> >> >> If the user's wallet acts as the AS issuing tokens, then there is zero >> need for this draft because we could pass the *scopes* that relate to >> the claims directly to the AS, and have the AS return a limited JWT, and we >> would actually do that every time because: >> >> 1. we can >> 2. because the tokens have short lifetime >> >> So that isn't a valid argument, unless there's a reason why the AS >> wouldn't be able to do this. >> >> >> Well, how many access tokens have you seen in the wild that only contain >> an access token? I haven’t, any of the carriers some for of user claims, >> e.g. a sub, in most cases some privileges/roles. Please take a look at >> https://www.rfc-editor.org/rfc/rfc9068.html for best current practice. >> >> Using a VC in the way I described means the original AS doesn’t need to >> be involved in the >> >> >> On Tue, Aug 2, 2022 at 10:14 AM Torsten Lodderstedt <torsten= >> 40lodderstedt....@dmarc.ietf.org> wrote: >> >>> >>> >>> Am 02.08.2022 um 09:53 schrieb Warren Parad <wparad= >>> 40rhosys...@dmarc.ietf.org>: >>> >>> >>> If we are in a offline scenario how does the verifier got ahold of the >>> public key associated with the id token? >>> >>> >>> Why id token? I would assume we are talking about verifiable >>> presentations, right? >>> >>> There are a couple of ways to provide the verifier with the public key >>> needed to verify. The (raw) key could be contained in the credential or the >>> presentation. If a trust chain is required, a x.509 certificate could serve >>> the same purpose. >>> >>> Beside that offline has different facets. In a Point of Sales scenario, >>> even though the wallet would be offline the checkout counter would most >>> likely have connectivity. That would also allow to resolve the public key >>> on demand. >>> >>> >>> They would need to be online, that defeats any benefit this could >>> provide. >>> >>> Or what if the token you have expires. Many providers issue tokens only >>> good for 1 hour. If that expires, the user has to go through the online >>> flow again. >>> >>> Unless we can add some provisions to ensure long lived token validity, I >>> think in practice we're cripling the usefulness. >>> >>> >>> Absolutely. That’s the reason a verifiable credential has a much longer >>> lifetime simply because the user should be able to use it in a sensible >>> way. As this makes replay more likely, all verifiable credentials formats >>> utilize holder binding for reply detection. The public key mentioned above >>> is part of the cryptographic holder binding that only the legitimate user >>> is able to execute. >>> >>> In an OAuth scenario, the user‘s wallet would act as AS and issue access >>> tokens (those could be short lived) that effectively are verifiable >>> presentations (based on a verifiable credential) audience restricted for a >>> certain RS. The client wouldn’t even know it’s a verifiable presentation >>> since the access token is opaque to the client. >>> >>> >>> >>> On Tue, Aug 2, 2022, 04:21 Kristina Yasuda <Kristina.Yasuda= >>> 40microsoft....@dmarc.ietf.org> wrote: >>> >>>> I support adoption. >>>> >>>> >>>> >>>> To add some color. >>>> >>>> >>>> >>>> One of the use-cases is a flow where issuance of a user credential >>>> (collection of user claims) is decoupled from presentation (where both >>>> issuance and presentation of a user credential are done using extensions of >>>> OAuth flows). The goal of this decoupling is to avoid “issuer call home”, >>>> where the user can send a user credential directly to the RP, without RP >>>> needing to contact the Issuer directly. So the motivations are not limited >>>> to offline scenarios, but are applicable to the scenarios that want to >>>> recreate in the online environment, the user experience of presenting >>>> credentials in-person. >>>> >>>> >>>> >>>> Driver’s Licence just happens to be an example familiar to many, and >>>> there is no reason it cannot be a diploma, or an employee card, or a >>>> training certificate, etc. But it is worth highlighting that SD-JWT work >>>> becomes critical if we are to enable ISO-compliant mobile Driver Licences >>>> expressed in JSON to enable online scenarios and make life of the Web >>>> developers easier (as opposed processing data encoded as CBOR and signed as >>>> a COSE message). Selective disclosure is a requirement in many government >>>> issued credentials, while the usage of advanced cryptography is not always >>>> encouraged by the national cybersecurity agencies. >>>> >>>> >>>> >>>> >>>> >>>> Regarding an approach where issuer issues multiple JWTs of a same type >>>> but with different subset of claims, it is not an ideal way to do selective >>>> disclosure with JWTs (type as a way to differentiate credential with one >>>> data structure/syntax from another). It complicates implementations that >>>> try to provide RP-U unlinkability (RPs cannot collude to track the user). >>>> The simplest way to achieve unlinkability with JWTs without using advanced >>>> cryptography is to issue multiple credentials of the same type but with >>>> varying use identifiers and enable pairwise identifiers per RP. Now there >>>> are multiple copies of each JWT with subset of claims of the same type. >>>> This greatly complicates presentation of these credentials too – since >>>> credentials are of the same type, now wallet needs to manage the >>>> combination of a subset of claims + pairwise identifier… >>>> >>>> >>>> >>>> What if the implementation also wants predicates property, where >>>> age_over_XX boolean is sent instead of a birthdate string? The simplest way >>>> to do predicates with JWTs without using advanced cryptography is to have >>>> issuers to issue multiple age_over_xx booleans so that an appropriate one >>>> can be selectively disclosed to the RP. How many “JWTs with subset of >>>> claims” does the issuer needs to issue to account for all possible age >>>> requirements? Note that it’s not just age_over_21 to start gambling, it’s >>>> also age_over_65 to get pension benefits. >>>> >>>> >>>> >>>> Managing the combinatorial explosion of sets of claims in speculatively >>>> issued JWTs, many of which will never be used, seems unwieldy, to say the >>>> least. "A conventional JWT with a subset of claims" approach could be taken >>>> in some implementations, but it should not prevent a simpler, extensible >>>> alternative of SD-JWT. >>>> >>>> >>>> >>>> >>>> >>>> Finally, as Giuseppe pointed out, an option to blind claim names is on >>>> the table. As discussed on this list previously, we should analyze privacy >>>> properties of the mechanism and decide if we want to mandate it – which can >>>> be discussed after the adoption. >>>> >>>> >>>> >>>> Best, >>>> >>>> Kristina >>>> >>>> >>>> >>>> >>>> >>>> *From:* OAuth <oauth-boun...@ietf.org> *On Behalf Of * Rifaat >>>> Shekh-Yusef >>>> *Sent:* Thursday, July 28, 2022 8:17 PM >>>> *To:* oauth <oauth@ietf.org> >>>> *Subject:* [OAUTH-WG] Call for adoption - SD-JWT >>>> >>>> >>>> >>>> All, >>>> >>>> >>>> >>>> This is a call for adoption for the *SD-JWT* document >>>> >>>> >>>> https://datatracker.ietf.org/doc/draft-fett-oauth-selective-disclosure-jwt/ >>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-fett-oauth-selective-disclosure-jwt%2F&data=05%7C01%7CKristina.Yasuda%40microsoft.com%7Ca2d72420ea2c40f2d7c908da70f7b388%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637946506426392735%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=d1EoHuRcBi40%2B1h1p5yZ28O7l8oq%2FibDewlJObT1Gwc%3D&reserved=0> >>>> >>>> >>>> >>>> Please, provide your feedback on the mailing list by *August 12th*. >>>> >>>> >>>> >>>> Regards, >>>> >>>> Rifaat & Hannes >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >>> _______________________________________________ > 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
