> 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=40danielfett...@dmarc.ietf.org> 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 < > d.w.chadw...@verifiablecredentials.info> wrote: > >> Answers inline below >> On 03/08/2022 14:57, Torsten Lodderstedt wrote: >> >> >> Am 02.08.2022 um 19:30 schrieb David Chadwick >> <d.w.chadw...@verifiablecredentials.info> >> <d.w.chadw...@verifiablecredentials.info>: >> >> >> >> 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 <wpa...@rhosys.ch>: >> >> 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= >> 40lodderstedt....@dmarc.ietf.org> wrote: >> >>> >>> >>> Am 02.08.2022 um 10:48 schrieb Warren Parad <wparad= >>> 40rhosys...@dmarc.ietf.org>: >>> >>> >>> 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= >>> 40lodderstedt....@dmarc.ietf.org> wrote: >>> >>>> >>>> >>>> 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? >>>> >>>> 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= >>>> 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/ >>>>>> <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 >>>>>> 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 >>> >>> >> >> _______________________________________________ >> OAuth mailing listOAuth@ietf.orghttps://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 >> > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://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
