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

[Warren Parad <[e-mail]>]

> and nobody involved in the JWP effort thinks that SD-JWT should be in
that WG once created

Why?

On Fri, Aug 5, 2022, 10:15 Daniel Fett <fett=[e-mail]>
wrote:

> Hi Jaimandeep,
> Am 04.08.22 um 20:39 schrieb Jaimandeep Singh:
>
> Dear All,
> My compliments to all the collaborators including David for making efforts
> in answering the queries. However, I am of the opinion that we need to
> answer some of the more fundamental questions before arriving at any
> decision.
>
> Let us first discuss if SD-JWT even meets the charter of the Working
> Group. We can divide the charter into smaller chunks and try to address
> each of them.
>
> (...)
>
>
> I am of the opinion that SD-JWT meets none of the objects set forward by
> the WG. Let us ask some further questions
>
> I don't think that the list of topics the WG is working on is meant as an
> exhaustive list. JWTs were originally specified here, as well as a lot of
> work based on JWTs. SD-JWT is a generic mechanism expanding what can be
> done with JWTs.
>
>
>
> Q1. What is the need of this feature?
> We have a client application that registers the scopes with the
> Authorization Server in the first place. We have a resource owner
> (end-user) who authorizes such claims. With the introduction of SD-JWT we
> are again going back the full circle and asking client applications as to
> what scopes it deems fit to disclose to the outside world, why on the earth
> it asked for the scopes that it never needed in the first place.
>
> Q2. It might not even meet the legal scrutiny. Why?
> Ans. When the user has authorized some scopes it is equivalent to 'click
> agreement'. Now, we are modifying those scopes with or without consent of
> the user. The client application is not bound to ask the user before
> preferring the SD-JWT claims to the Resource Server. Here we are
> challenging the complete concept of OAuth 2.0.
>
> You seem to be missing that whatever an AS releases or allows is not
> touched by SD-JWT. When used for identity claims, SD-JWT allows the
> end-user to release *less* than what was put into a credential by an
> identity provider to the relying party. Other use cases are conceivable,
> e.g., for access tokens, but the point here is that for the selective
> disclosure aspect, user and whatever software they use both have an
> interest to release *less* data to whoever gets the data.
>
>
>
> Q3. Is adoption of SD-JWT recommended in any of the draft documents like
> OAuth 2.1 or Best Security Practices?
> Ans. As of now we have not found any suitable place for introducing it
> into the ecosystem.
>
> The question you ask is misleading. Both OAuth 2.1 and the Security BCP
> not only predate SD-JWT by years, they are also concerned with traditional
> OAuth deployments. SD-JWT is a new feature for new deployments with
> specific requirements. Most deployments will not have any use for SD-JWT,
> and we will not bother them with adopting it, but for those that do, SD-JWT
> is an excellent alternative to other existing approaches. We will for sure
> not recommend SD-JWT as a mechanism for all OAuth setups, but SD-JWT will
> help to establish OAuth/OIDC in SSI and similar use cases.
>
>
>
> Q3. Is there any other WG which is trying to solve the similar problem of
> SD-JWT?
> Ans. Yes, WG-JWP (JSON Web Proofs) may be a more suitable place for the
> adoption of SD-JWT as they are working on a similar set of problems.
> They are actively seeking participation in the area of SD-JWT.
>
> JWPs use advanced cryptography and a completely new format to solve the
> selective disclosure problem, but also many more things that SD-JWT cannot
> do. However, SD-JWT is available today, with four running implementations
> already, it is designed to be easily understood and implemented, and based
> on existing mechanisms (essentially, JWTs + hashing). As far as I am aware,
> a JWP WG is not chartered yet, and nobody involved in the JWP effort thinks
> that SD-JWT should be in that WG once created.
>
>
>
> In my opinion, the SD-JWT is well thought out and a lot of hard work has
> gone behind it. However, this WG is not the right place for adoption as we
> have to work on more serious and immediate issues at hand. We may consider
> its adoption at a later time frame when we gain more maturity on how things
> are going forward.
>
> You seem to imply that adopting SD-JWT would slow down work on other
> topics considerably. I don't think that that would be the case, given that
> other work in this group will not depend on SD-JWT. Also, with large
> projects world wide looking for credential formats such as SD-JWT, I think
> this is a somewhat serious and immediate topic.
>
> -Daniel
>
>
>
> Regards and Best Wishes
> Jaimandeep Singh
>
> On Thu, Aug 4, 2022 at 9:17 PM David Chadwick <
> [e-mail]> wrote:
>
>> Answers inline below
>> On 03/08/2022 14:57, Torsten Lodderstedt wrote:
>>
>>
>> Am 02.08.2022 um 19:30 schrieb David Chadwick
>> <[e-mail]>
>> <[e-mail]>:
>>
>> 
>>
>> Hi Torsten
>>
>> your use case sounds like an online use case, not an offline one. So its
>> a question of balancing a long lived SD-JWT along with a revocation
>> mechanism vs a short lived minimal JWT containing just the claims that are
>> needed.
>>
>> That’s correct.
>>
>> I thought that SAML, OAuth2 and OIDC had opted for short lived
>> non-revocable claims rather than long lived revocable ones due to the
>> experiences of using revocation with X.509 PKCs.
>>
>> SAML and OIDC are considerably simple, flexible, and secure solutions to
>> the challenges of selective disclosure, direct identifiers, and current
>> claim values.
>>
>>
>> However they tend to support maximum privileges/attribute release rather
>> than minimum privileges because they are provided at user login, before the
>> RP knows what the user wants to do. So often more user PII  than is
>> required is released. OIDC4VPs allows us to solve this with SD and
>> incremental releases of claims as the user progressively request to do more
>> sensitive transactions. (By the way this is what we implemented in a
>> non-standard way prior to the W3C VC DM being published. It is documented
>> in the IEEE Comms Standard, viz:
>>
>> David W Chadwick, Romain Laborde, Arnaud Oglaza, Remi Venant, Samer
>> Wazan, Manreet Nijjar “Improved Identity Management with Verifiable
>> Credentials and FIDO”. IEEE Communications Standards Magazine. Vol 3, Issue
>> 4, Dec 2019, Pages 14-20)
>>
>>
>> They are an excellent solution for Web SSO. However, they require the IDP
>> to be always on, an online connection to the RP, and share a lot of
>> metadata with the IDP.
>>
>> I would think that always online is not an issue in today's
>> interconnected world. Rather users expect everything to online 24/24 as do
>> businesses. I suspect any service that is not online 24/24 is the odd one
>> out and disliked by most people. Plus the revocation service has to online
>> 24/24
>>
>>
>> X.509 certificate never had those problems, but are inflexible and
>> require revocation. Verifiable Credentials to me are more like X.509 certs
>> but with more flexibility, simpler to use data formats, and the option to
>> selectively disclose claims.
>>
>> So the question merely is what parameters to optimize for.
>>
>> Agreed, its all about making choices and balancing security, privacy,
>> usability and trust
>>
>>
>>
>> The current thinking I perceive is to give users long lived credentials,
>> which means the issuer doesn’t need to be always on, there is no need for
>> online connection, and the issuer does not get any metadata on when, what
>> kind of claims is being used. This also makes offline use of such
>> credentials an obvious option.
>>
>> Which essentially boils down to short lived unrevocable vs. long lived
>> revocable. The mDL solution of a relatively long lived credentials without
>> revocation might be OK for a driving license that changes infrequently. But
>> this is not a model that will satisfy all verifiable credentials. Also mDL
>> does mean that the IDP will need to be almost always online for users to
>> refresh their credentials when they have expired.
>>
>> In a way you are swapping the IDP being always on, to the revocation
>> service being always on and an IDP that is periodically on to update it.
>> The problem we have seen with this approach in the X.509 world, is that if
>> the revocation service is not available, browsers have switched from a hard
>> fail (which the standard mandates) to a soft fail so that the users can
>> continue working, which leads to an obvious vulnerability of using a
>> revoked certificate. If the IDP is not on, then a hard fail is inevitable
>> with OIDC, and users will soon require the service to resume again so that
>> they can get back to work. So the latter is more secure though less usable
>> (which X.509 used to support with its hard fail). I suspect that in some
>> use cases (maybe financial ones?) hard fails are preferable to soft fails?
>>
>>
>> However, the lifecycle of such credentials needs to be managed. I think
>> revocation lists are an ok solution to that problem. I don’t see how the
>> issuer could learn where a credential is being used with revocation lists
>> as the verifier will just download the whole list for evaluation and
>> revocation lists typically do not authenticate the verifier. Which leaves
>> the IP address of the verifier as metadata without any further context.
>>
>> True, a well designed revocation scheme leaks less information to the IDP.
>>
>>
>> I think the issuer part of it is more complex than people currently
>> believe since issuers need to maintain a list of the credentials they
>> issued (not needed in OIDC). Updates to credential data need to be
>> published and last but not least, there needs to be away to let credentials
>> be revoked. E.g. an user or a wallet provider might need to ask an issuer
>> to revoke a certain credential because of abuse.
>>
>> Does this not imply that the IDP has to always on for the user to report
>> a problem??? Which was something you wanted to escape from.
>>
>>
>> That’s gone be though.
>>
>> Seems like the above was a typo.
>>
>>
>>
>> That might be the reason why ISO mDL uses expiration (I guess weeks to
>> month) instead of revocation. And the wheel starts to turn again …
>>
>>
>> Exactly. Because there is no perfect solution, but only one that
>> compromises one feature for another. So in the end if the users decide
>> which is preferrable, it will mean that usability wins and trumps security
>> and privacy concerns!! If service providers decide they may opt for hard
>> fails with security and privacy trumping usability.
>>
>> Which brings me to the conclusion that long lived one-time use VCs with
>> soft revocation (i.e. continue as if everything is OK if revocation info is
>> not available) with blinded property names and values is the best
>> compromise from a usability perspective i.e. one time use privacy enhanced
>> SD-JWTs. I wonder how many wallets can currently handle this? I guess zero
>> at the moment, but its an objective worth aiming for. Alternatively short
>> lived one-time use VCs with no revocation, that are issued periodically or
>> on demand (dependent upon the validity period) is the best option from a
>> security and privacy perspective. If the IDP is not available the user will
>> not be able to do any work once his stock of short lived credentials are
>> exhausted.
>>
>> Do you agree?
>>
>> Kind regards
>>
>> David
>>
>> Kind regards
>>
>> David
>> On 02/08/2022 10:47, Torsten Lodderstedt wrote:
>>
>>
>> Am 02.08.2022 um 11:06 schrieb 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?
>>
>>
>> In the model I envision, OAuth clients are able to obtain access tokens
>> for the user’s services through the user’s wallet. Since the wallet is not
>> the AS the RS trusts, I would like to utilize verifiable credentials as
>> basis for issuing access tokens from the wallet. That means the credential
>> is issued by the AS and the wallet can mint access tokens containing a
>> presentation of such a credential. From a RSs standpoint this retains the
>> standard trust model since the RS only accepts access tokens containing a
>> credential from an AS it trusts.
>>
>> I also assume that a single AS is managing access to several RSs as that
>> was the case in almost all deployments I was involved with.
>>
>> I think the most efficient and flexible way to implement this scenario is
>> to issue a single SD-JWT based credential and to mint RS-specific access
>> token as needed by using SD-JWT’s selective disclosure capabilities. So an
>> access token for the user’s contacts API would only include the claims
>> needed for this service (e.g. the privilege to use the service) whereas an
>> access token for the streaming API would include the data needed there
>> (e.g. authorised channel lists and so on).
>>
>>
>> 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
>>>
>>>
>>
>> _______________________________________________
>> OAuth mailing [e-mail]://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
>>
>
> _______________________________________________
> OAuth mailing [e-mail]://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>