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

[Daniel Fett <[e-mail]>]

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]>
>>>     <mailto:[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 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 list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth