> Am 02.08.2022 um 10:48 schrieb Warren Parad > <[email protected]>: > > > 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 >> <[email protected]> wrote: >> >> >>>> Am 02.08.2022 um 10:35 schrieb Warren Parad >>>> <[email protected]>: >>>> >>> >>> Why would we not include those seemingly critical details in the draft then? >>> Let's define what a verifiable presentation is (is that already defined >>> somewhere? I didn't see it in the draft) >>> 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: >>> we can >>> 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 >>>> <[email protected]> wrote: >>>> >>>> >>>>>> Am 02.08.2022 um 09:53 schrieb Warren Parad >>>>>> <[email protected]>: >>>>>> >>>>> >>>>> 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 >>>>>> <[email protected]> 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 <[email protected]> On Behalf Of Rifaat Shekh-Yusef >>>>>> Sent: Thursday, July 28, 2022 8:17 PM >>>>>> To: oauth <[email protected]> >>>>>> 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/ >>>>>> >>>>>> >>>>>> >>>>>> Please, provide your feedback on the mailing list by August 12th. >>>>>> >>>>>> >>>>>> >>>>>> Regards, >>>>>> >>>>>> Rifaat & Hannes >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> [email protected] >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
