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

Tue, 02 Aug 2022 10:16:38 -0700

Kristina, a correction to your statement below if I may. Whilst it is true that the Issuer will know when approximately the user is presenting a subset of claims, the Issuer will NOT know where the user is presenting them i.e. details of the RP are not fed back to the OP. Furthermore if this is a serious concern, the wallet could periodically ask for credentials and throw them away, to obfuscate when they are actually being used.

However, using long lived credentials as you propose have a potentially worse privacy leak: if revocation is not implemented properly the issuer will know which RP is requesting to know which credential has/hasn't been revoked and therefore when and where the user is using it. And as we know, revocation has proven to be something of nightmare for PKI. So it may prove to be for long lived verifiable credentials as well.

Kind regards

David

On 02/08/2022 15:58, Kristina Yasuda wrote:

Maybe - If we want to force a Client to make a network call every time it receives a request to present a credential, while there is an alternative approach that allows the Client to generate on its own a presentation response with a required subset of claims. But why would we want to do that?

 

The former approach of "issuance during presentation" has been discussed and is not as simple as it may sound - it requires defining query syntax to request specific subset of the whole credential in the Credential Request, an additional mechanism to communicate versions of the credential between Client and the Server, etc. The Issuer will also always know where and when the user is presenting which subset of claims, so no point decoupling issuance from presentation in the first place. 

 

From: OAuth <oauth-boun...@ietf.org> On Behalf Of Warren Parad
Sent: Tuesday, August 2, 2022 7:56 AM
To: David Chadwick <d.w.chadw...@verifiablecredentials.info>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Call for adoption - SD-JWT

 

In the case we do that, this spec doesn't add value, right?

 

On Tue, Aug 2, 2022, 13:39 David Chadwick <d.w.chadw...@verifiablecredentials.info> wrote:

Hi Warren

I am speaking about the verifiable credential issuing process where the user/wallet is the client and the credential issuing system is the authoriser and operates the AS and RS. (This is the model describes in the OIDC4VCI spec.)

So the AS issues the access token to the user/wallet. This is then sent to the RS to obtain the verifiable credential. So I was asserting that if the user/wallet has an access token for a complete verifiable credential, then it should be able to ask for a set of subset credentials either concurrently or sequentially, dependent upon the policy of the RS.

Does this make sense to you now?

Kind regards

David

On 01/08/2022 18:24, Warren Parad wrote:

Hey David, would you be able to go back and reread what you wrote? I'm trying to parse it and it seems what you are calling different things don't align to the common understanding of what AS/RS/client mean.

 

For instance:

  • the user, not the AS, authorizes a client to attain credentials
  • the client doesn't ask the RS for anything other than the managed resources using the credentials
  • the client in this case is likely a hardware device that runs the user-agent so in practice it will have and know 100% of the user's data
  • AS issues credentials, that is its job, saying "it shouldn't be involved" is the same as saying "I don't want to use OAuth for this" (which is fine, but likely that's the important part)
  • RS doesn't decide HOW it decides IF, the HOW is decided by the RS' api documentation and published expectations

To avoid potential miscommunication, about what these are and how they work, can I suggest first outlining a concrete situation, and then identifying how you would expect the agents would interact with each other. We can do the messy part of assigning "which is the AS" and "which is the RS or the client" afterwards. But having the hypothetical model would go a long way.

 

On Mon, Aug 1, 2022 at 6:56 PM David Chadwick <d.w.chadw...@verifiablecredentials.info> wrote:

Hi Aaron

I think we have different mental models for this. In my opinion, if the AS authorises the client to obtain a complete credential with all the properties, then the client should be able to ask the RS for a set of subsets of the credential, since the client is not obtaining more than what has been authorised. I do not think that the AS should be involved in the credential issuing process. It is for the RS to decide how to honour the client's request.

Kind regards

David

On 01/08/2022 17:34, Aaron Parecki wrote:

David,

 

Creating "A conventional JWT with a subset of claims" is exactly the thing this draft sets out to prevent needing to do. The problem with that approach is the AS would have to create a new JWT with only the claims needed for the particular presentation, so the AS would need to be both accessible (online) by the client as well as aware of the request. These are both properties avoided by the SD-JWT draft, perhaps these can be clarified in the introduction. 

 

Aaron Parecki

 

 

 

 

On Mon, Aug 1, 2022 at 9:22 AM David Chadwick <d.w.chadw...@verifiablecredentials.info> wrote:

thanks Guiseppe. Glad to hear that blinding claim names is now on the cards.

This does not answer the question about why conventional JWTs with a subset of the claims cannot also be used

Kind regards

David

On 01/08/2022 17:04, Giuseppe De Marco wrote:

Hi David,

 

This issue was already raised.

Below the proposal for both draft and python code

 

 

Regarding the privacy I'd like to have a combined presentation format that makes the PID/QEAA (VC) untraceable (jwe, with variable iat claim value). You find some open issues for joining in the discussion

 

Best

 

Il lun 1 ago 2022, 14:50 David Chadwick <d.w.chadw...@verifiablecredentials.info> ha scritto:

I would like to add a few further points.

The age-over property is more complex than your example, because a driving license only contains the date of birth. The issuing authority decides which age-over properties to statically provide in the mDL and the ISO standard provides an algorithm of how the wallet should respond if the age-over being requested is not present in the mDL. So different mDLs may contain different age-over properties and respond differently to requests for age-over from two people of the same age.

The ISO mDL selective disclosure is more privacy protecting than the proposed SD-JWT because it also blinds the property names as well as the values.

The examples below do not say why the use cases cannot work if the wallet has a set of conventional JWTs containing different commonly requested subsets of claims, such as age or address or classes of vehicle one can drive.

Kind regards

David

On 01/08/2022 13:24, Warren Parad wrote:

This is done because network availability and privacy concerns may separate the act of acquiring the SD-JWT of a license from the issuing authority, and presenting it (such as days later during a traffic stop on a mountain road).

 

I think we keep pointing to "offline drivers license" as the only reason we have this draft. But we still haven't made clear why the "offline drivers license" actually needs this. I spent some real time thinking about and came up with two hypotheticals that helped me.

 

Hypothetical 1:

You are on a mountain road and a police officer pulls you over, it's late at night, you have no internet, and your driver license is 100% digital.

 

The officer wants to know if you live in the area, or if you are from out of state. You don't want to tell the police officer your name, you click some magic buttons on your device, and a QR code pops up. This QR code contains only:

  • "id_token" with salted fields
  • selective disclosure for: address city + state

 

The police officer's magic new special SD-JWT device tells them you have a valid driver's license and that you live in the area. The officer is either:

  • Okay with that
  • Asks for further disclosure, which you can agree to or risk being arrested and brought in for questioning.

 

Hypothetical 2:

You live in the US and going out to a bar. Bars in the US are infamous for carding people. You want to tell them that you are over 21, but don't want to tell them anything else. So you take out your digital wallet and show them a QR code that only contains:

  • "id_token" with salted fields
  • selective disclosure for: over 21

The bouncer uses their magic new SD-JWT device to verify that information, and can either say:

  • That's sufficient, come on in
  • I don't believe that is yours, I need to see your picture (including details), your name as well as another form of identification.

 

Problem from 2:

The bouncer says, I need to know you have been vaccinated against covid in the last 6 months. Here's where things start to get challenging, did the issuer have this information available to create a claim that could be selectively disclosed?

 

Do we need to maintain a registry of all the allowed claims, or are countries some how going to be on top of this?

 

What happens when different countries have different "standard claims"?

 

 

On Mon, Aug 1, 2022 at 1:29 PM David Chadwick <d.w.chadw...@verifiablecredentials.info> wrote:

 

On 01/08/2022 11:55, Neil Madden wrote:

I agree with many of these points that Jaimandeep Singh raises. 

 

It would be good to know exactly what the intended use-cases within OAuth are. In particular, in OAuth it’s normally the case that the client is relatively untrusted and a privacy goal is to avoid revealing information/PII to the client unnecessarily. In SD-JWT it seems that this is turned on its head somewhat and we trust the client (holder) with everything and instead want to keep some information private from the resource servers?

 

I think there are also some questions about exactly which claims can be selectively disclosed - e.g., it would be a very bad idea to allow security constraints like “exp”, “aud” or “cnf” to be selectively (not) disclosed. But the problem is that the set of security constraints is not fixed in any way, and new ones may be added by future specs or application-specific ones. So the issuer will need to be careful not to allow such constraints to be selectively disclosed.

 

Ultimately, I just don’t find this idea of fine-grained pick ’n’ mix selective disclosure of individual claims to be very compelling compared to the much simpler solution of just issuing multiple JWTs in the first place (with appropriate subsets of claims in them).

+1. This is exactly what we do

David

 

— Neil

 

On 29 Jul 2022, at 03:15, Jaimandeep Singh <jaimandeep.phdcs21=40nfsu.ac...@dmarc.ietf.org> wrote:

 

Dear All,

1. At the outset I must compliment  Daniel Fett and Kristina Yasudafor and all the contributors for the wonderful work done on SD-JWT.

2. However, in my opinion there is no clear motivation for using SD-JWT in the present oAuth 2.0/2.1 ecosystem. We already have JWS and JWE which more or less satisfy the requirements.

3. The focus and time of the WG-OAUTH should be more aligned to the work directly impacting the improvements or BCP in the oAuth 2.0/2.1 specs.

4. 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.

5. In view of above I am presently not in favour of its adoption in WG-OAUTH. 

 

Regards

Jaimandeep Singh

 

On Fri, Jul 29, 2022 at 6:43 AM Brian Campbell <bcampbell=40pingidentity....@dmarc.ietf.org> wrote:

I support adoption.

On Thu, Jul 28, 2022, 8:17 PM Rifaat Shekh-Yusef <rifaat.s.i...@gmail.com> wrote:

All,

 

This is a call for adoption for the SD-JWT document

 

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


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._______________________________________________
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 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 list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--

---

Aaron Parecki

 

_______________________________________________
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

Reply via email to