> 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? > 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 issuance of the actual access token, which adds to privacy and scalability. > >> 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/ >>>> >>>> >>>> >>>> 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
