Re: [OAUTH-WG] Call for adoption - SD-JWT

[Warren Parad <[e-mail]>]

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=
[e-mail]> wrote:

>
>
> Am 02.08.2022 um 10:48 schrieb Warren Parad <wparad=
> [e-mail]>:
>
> 
> 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=
> [e-mail]> wrote:
>
>>
>>
>> Am 02.08.2022 um 10:35 schrieb Warren Parad <wparad=
>> [e-mail]>:
>>
>> 
>> 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=
>> [e-mail]> wrote:
>>
>>>
>>>
>>> Am 02.08.2022 um 09:53 schrieb Warren Parad <wparad=
>>> [e-mail]>:
>>>
>>> 
>>> 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=
>>> [e-mail]> 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 <[e-mail]> *On Behalf Of * Rifaat
>>>> Shekh-Yusef
>>>> *Sent:* Thursday, July 28, 2022 8:17 PM
>>>> *To:* oauth <[e-mail]>
>>>> *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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>