subject:"\[OAUTH\-WG\] Call for adoption \- SD\-JWT"

So the executive summary is "JWP does solve this problem, but that work
isn't close to being able to provide a solution yet" Or is it something
else?

On Fri, Aug 5, 2022 at 5:22 PM David Waite  wrote:

> I can’t speak to what group or charter the JWP work would eventually be
> under, but the JWT specification is one of several examples of a
> specification that heavily leveraged the JOSE work but which was started
> here at OAUTH, outside of the (at the time active) JOSE WG.
>
> Without perusing old email archives across two groups, I speculate that
> this is because JWTs are at a different layer than JOSE - the JOSE
> specifications defined algorithms and serializations for cryptographic
> messages, while JWT defined (generalized) application-layer semantics. JWS
> and JWE allows for arbitrary binary payloads, while JWT mandates a specific
> document format - a JSON object of higher-layer security and subject
> claims.
>
> Likewise, other groups and individuals outside of OAUTH have further
> defined how to process JWTs for their own specific application space, just
> like OAUTH produced a specification recommending how to use JWTs for access
> tokens.
>
> To have SD-JWT under the JOSE group (or another JWP group) would mean that
> it was chartered to define such application-layer semantics, in addition to
> the lower layer work of specifying algorithms and serialization of
> cryptographic data.
>
> SD-JWT is an incremental addition on top of JWTs; while it does need a new
> compact representation to express additional information, the idea is that
> it can be implemented as incremental logic on top of existing JWT
> processing libraries. This is core to the current design, and why there are
> already multiple implementations of the draft.
>
> JWP does envision a different approach from SD-JWT, where you have the
> concept of multiple (potentially binary) payloads as part of the core data
> model and serializations. A JWT/SD-JWT equivalent (such as JPTs -
> https://www.ietf.org/id/draft-jmiller-jose-json-proof-token-00.html )
> would define how claims are mapped to particular payloads in a JWP.
>
> To avoid going too deeply into my own biases here, I think the approach
> defined by JWP has many benefits. However, that work is just beginning.
>
> Similar to how the work on TLS 1.3 didn’t stop people from specifying new
> capabilities for TLS 1.2, I don’t think the eventual goals of JWP+JPT
> should detract from specifying SD-JWT.
>
> -DW
>
> On Aug 5, 2022, at 3:28 AM, Warren Parad  40rhosys...@dmarc.ietf.org> wrote:
>
> Maybe they have a good reason for not wanting it, and then we shouldn't be
> the WG that backdoor's it in. Also: "other people have already implemented
> it" is a cognitive fallacy, so let's not use that as a justification we
> have to make the standard.
>
> We should get a concrete reason why a WG that seems like the appropriate
> one, thinks it wouldn't make sense. If it is just a matter of timing, then
> whatever. But if there are concrete recommendations from that group, I
> would love to hear them.
>
> On Fri, Aug 5, 2022 at 10:26 AM Daniel Fett  40danielfett...@dmarc.ietf.org> wrote:
>
>> Am 05.08.22 um 10:22 schrieb Warren Parad:
>>
>> > and nobody involved in the JWP effort thinks that SD-JWT should be in
>> that WG once created
>>
>> Why?
>>
>> For the reasons listed, I guess?
>>
>> Also, mind the "As far as I am aware" part, but I don't remember any
>> discussions in that direction at IETF114.
>>
>> -Daniel
>>
>> ___
>> 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

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

Can you list them out succinctly, because I don't feel like they have been?
The reason I say that, is if all the entities are online, then the AS can
directly issue the restricted token. So the only argument I can see there
is "We want to reduce the load on AS by delegating some proportion of the
AS responsibilities to the user's client". Although in that case, should we
really stop at SD-JWT, or should we go for a solution that actually allows
user-clients issued tokens to do more than share user claim values?

On Fri, Aug 5, 2022 at 3:32 PM Kristina Yasuda  wrote:

> Yes, SD-JWT is not complete and that’s exactly why we are asking for a WG
> adoption. The questions you are asking are better answered in the WG,
> post-adoption.
>
> Thank you,
> Kristina
>
> PS. Offline claim transmission is not the only “feature” of SD-JWT for all
> of the reasons that have been previously outlined in this thread.
>
> --
> *De :* OAuth  de la part de Warren Parad  40rhosys...@dmarc.ietf.org>
> *Envoyé :* vendredi, août 5, 2022 6:25 AM
> *À :* Daniel Fett
> *Cc :* oauth@ietf.org
> *Objet :* Re: [OAUTH-WG] Call for adoption - SD-JWT
>
> It's clear that good thought has been put into the core of it, more so
> than other drafts submitted, but not yet feature complete.
>
> For example there is no sense of how the private/public key exchange
> actually happens. In *holder binding *scenario, it isn't detailed how to
> actually include the public key in the sub_jwk claim, or what a "reference"
> to the public key actually means. Is the server an AS as in OAuth?, or are
> we building on top of another token creation standard? If it is OAuth, It
> isn't clear if we need a new indicator in the token response that tells us
> that the salt container is attached to the token and that it shouldn't
> blindly be passed along. It isn't clear from this discussion if we need
> token revocation.
>
> Assuming it is the OAuth token exchange that we are building on top of,
> there are lots of open questions of interoperability. I.e. Does the digest
> go in the access token? If it isn't OAuth, we don't have any guide on how
> to actually do the token generation, how to verify the signature of the
> token with the digest, and I'm sure there are more things.
>
> We don't need to have both in the same WG, that wasn't my point, the point
> is if there is a concrete reason that others aren't working on it, I wanted
> to know why. There are JWPs, I don't know anything about them, but it
> doesn't really matter if they have different approaches, different cryptos,
> etc... Let's look at the features, that's at the core of what matters. So
> far the only feature we've been able to nail down is *offline claim
> transmission*. Will JWPs support *offline claim transmission*?
>
> On Fri, Aug 5, 2022 at 11:55 AM Daniel Fett  40danielfett...@dmarc.ietf.org> wrote:
>
>> It's not that the people I have spoken to didn't like the idea of SD-JWT.
>> It's just on a different layer than JWPs, using a different approach,
>> different crypto, providing different features, and on a different
>> timeline. There's no compelling reason to have both in the same WG. There
>> are nonetheless good reasons to have SD-JWT. Having SD-JWT in OAuth WG is
>> not an attempt to "backdoor" anything in!
>>
>> I also didn't say that we should adopt SD-JWT because it has been
>> implemented. You took my statement out of context. I wanted to underline
>> that the spec is practically feature-complete and can be implemented today,
>> providing the features promised. Meanwhile, JWP is not there yet.
>>
>> But, SD-JWT is not in production yet. If the OAuth WG decides that
>> substantial changes are required, now is the best time for that.
>>
>> Also, I wanted to highlight with my statement that SD-JWT is easy to
>> implement due to its simplicity.
>>
>> -Daniel
>>
>> Am 5. August 2022 11:28:49 MESZ schrieb Warren Parad > 40rhosys...@dmarc.ietf.org>:
>>>
>>> Maybe they have a good reason for not wanting it, and then we shouldn't
>>> be the WG that backdoor's it in. Also: "other people have already
>>> implemented it" is a cognitive fallacy, so let's not use that as a
>>> justification we have to make the standard.
>>>
>>> We should get a concrete reason why a WG that seems like the appropriate
>>> one, thinks it wouldn't make sense. If it is just a matter of timing, then
>>> whatever. But if there are concrete recommendations from that group, I
>>> would love to hear them.
>>>
>>> On Fri, Aug 5, 2022 at

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

2022-08-05 Thread David Waite

I can’t speak to what group or charter the JWP work would eventually be under, 
but the JWT specification is one of several examples of a specification that 
heavily leveraged the JOSE work but which was started here at OAUTH, outside of 
the (at the time active) JOSE WG.

Without perusing old email archives across two groups, I speculate that this is 
because JWTs are at a different layer than JOSE - the JOSE specifications 
defined algorithms and serializations for cryptographic messages, while JWT 
defined (generalized) application-layer semantics. JWS and JWE allows for 
arbitrary binary payloads, while JWT mandates a specific document format - a 
JSON object of higher-layer security and subject claims. 

Likewise, other groups and individuals outside of OAUTH have further defined 
how to process JWTs for their own specific application space, just like OAUTH 
produced a specification recommending how to use JWTs for access tokens.

To have SD-JWT under the JOSE group (or another JWP group) would mean that it 
was chartered to define such application-layer semantics, in addition to the 
lower layer work of specifying algorithms and serialization of cryptographic 
data.

SD-JWT is an incremental addition on top of JWTs; while it does need a new 
compact representation to express additional information, the idea is that it 
can be implemented as incremental logic on top of existing JWT processing 
libraries. This is core to the current design, and why there are already 
multiple implementations of the draft.

JWP does envision a different approach from SD-JWT, where you have the concept 
of multiple (potentially binary) payloads as part of the core data model and 
serializations. A JWT/SD-JWT equivalent (such as JPTs -  
https://www.ietf.org/id/draft-jmiller-jose-json-proof-token-00.html ) would 
define how claims are mapped to particular payloads in a JWP.

To avoid going too deeply into my own biases here, I think the approach defined 
by JWP has many benefits. However, that work is just beginning. 

Similar to how the work on TLS 1.3 didn’t stop people from specifying new 
capabilities for TLS 1.2, I don’t think the eventual goals of JWP+JPT should 
detract from specifying SD-JWT.

-DW

> On Aug 5, 2022, at 3:28 AM, Warren Parad  
> wrote:
> 
> Maybe they have a good reason for not wanting it, and then we shouldn't be 
> the WG that backdoor's it in. Also: "other people have already implemented 
> it" is a cognitive fallacy, so let's not use that as a justification we have 
> to make the standard.
> 
> We should get a concrete reason why a WG that seems like the appropriate one, 
> thinks it wouldn't make sense. If it is just a matter of timing, then 
> whatever. But if there are concrete recommendations from that group, I would 
> love to hear them.
> 
> On Fri, Aug 5, 2022 at 10:26 AM Daniel Fett 
> mailto:40danielfett...@dmarc.ietf.org>> 
> wrote:
>> Am 05.08.22 um 10:22 schrieb Warren Parad:
>>> > and nobody involved in the JWP effort thinks that SD-JWT should be in 
>>> > that WG once created
>>> 
>>> Why?
>> For the reasons listed, I guess?
>> 
>> Also, mind the "As far as I am aware" part, but I don't remember any 
>> discussions in that direction at IETF114.
>> 
>> -Daniel
>> 
>> 
>> ___
>> 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

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

2022-08-05 Thread Kristina Yasuda

Yes, SD-JWT is not complete and that’s exactly why we are asking for a WG
adoption. The questions you are asking are better answered in the WG,
post-adoption.

Thank you,
Kristina

PS. Offline claim transmission is not the only “feature” of SD-JWT for all of
the reasons that have been previously outlined in this thread.

De : OAuth de la part de Warren Parad

Envoyé : vendredi, août 5, 2022 6:25 AM
À : Daniel Fett
Cc : oauth@ietf.org
Objet : Re: [OAUTH-WG] Call for adoption - SD-JWT

It's clear that good thought has been put into the core of it, more so than
other drafts submitted, but not yet feature complete.

For example there is no sense of how the private/public key exchange actually
happens. In holder binding scenario, it isn't detailed how to actually include
the public key in the sub_jwk claim, or what a "reference" to the public key
actually means. Is the server an AS as in OAuth?, or are we building on top of
another token creation standard? If it is OAuth, It isn't clear if we need a
new indicator in the token response that tells us that the salt container is
attached to the token and that it shouldn't blindly be passed along. It isn't
clear from this discussion if we need token revocation.

Assuming it is the OAuth token exchange that we are building on top of, there
are lots of open questions of interoperability. I.e. Does the digest go in the
access token? If it isn't OAuth, we don't have any guide on how to actually do
the token generation, how to verify the signature of the token with the digest,
and I'm sure there are more things.

We don't need to have both in the same WG, that wasn't my point, the point is
if there is a concrete reason that others aren't working on it, I wanted to
know why. There are JWPs, I don't know anything about them, but it doesn't
really matter if they have different approaches, different cryptos, etc...
Let's look at the features, that's at the core of what matters. So far the only
feature we've been able to nail down is offline claim transmission. Will JWPs
support offline claim transmission?

On Fri, Aug 5, 2022 at 11:55 AM Daniel Fett
mailto:40danielfett...@dmarc.ietf.org>>
wrote:
It's not that the people I have spoken to didn't like the idea of SD-JWT. It's
just on a different layer than JWPs, using a different approach, different
crypto, providing different features, and on a different timeline. There's no
compelling reason to have both in the same WG. There are nonetheless good
reasons to have SD-JWT. Having SD-JWT in OAuth WG is not an attempt to
"backdoor" anything in!

I also didn't say that we should adopt SD-JWT because it has been implemented.
You took my statement out of context. I wanted to underline that the spec is
practically feature-complete and can be implemented today, providing the
features promised. Meanwhile, JWP is not there yet.

But, SD-JWT is not in production yet. If the OAuth WG decides that substantial
changes are required, now is the best time for that.

Also, I wanted to highlight with my statement that SD-JWT is easy to implement
due to its simplicity.

-Daniel

Am 5. August 2022 11:28:49 MESZ schrieb Warren Parad
mailto:40rhosys...@dmarc.ietf.org>>:
Maybe they have a good reason for not wanting it, and then we shouldn't be the
WG that backdoor's it in. Also: "other people have already implemented it" is a
cognitive fallacy, so let's not use that as a justification we have to make the
standard.

We should get a concrete reason why a WG that seems like the appropriate one,
thinks it wouldn't make sense. If it is just a matter of timing, then whatever.
But if there are concrete recommendations from that group, I would love to hear
them.

On Fri, Aug 5, 2022 at 10:26 AM Daniel Fett
mailto:40danielfett...@dmarc.ietf.org>>
wrote:
Am 05.08.22 um 10:22 schrieb Warren Parad:
> and nobody involved in the JWP effort thinks that SD-JWT should be in that WG
> once created

Why?

For the reasons listed, I guess?

Also, mind the "As far as I am aware" part, but I don't remember any
discussions in that direction at IETF114.

-Daniel

___
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth=05%7C01%7CKristina.Yasuda%40microsoft.com%7C03ac1c4a32f6457e128a08da76ccd39d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637952919372957096%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=aiBKf9gkCbDEgNPVKHWFPABIHS1s9rSrwSSI%2FVDLmuA%3D=0>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

It's clear that good thought has been put into the core of it, more so than
other drafts submitted, but not yet feature complete.

For example there is no sense of how the private/public key exchange
actually happens. In *holder binding *scenario, it isn't detailed how to
actually include the public key in the sub_jwk claim, or what a "reference"
to the public key actually means. Is the server an AS as in OAuth?, or are
we building on top of another token creation standard? If it is OAuth, It
isn't clear if we need a new indicator in the token response that tells us
that the salt container is attached to the token and that it shouldn't
blindly be passed along. It isn't clear from this discussion if we need
token revocation.

Assuming it is the OAuth token exchange that we are building on top of,
there are lots of open questions of interoperability. I.e. Does the digest
go in the access token? If it isn't OAuth, we don't have any guide on how
to actually do the token generation, how to verify the signature of the
token with the digest, and I'm sure there are more things.

We don't need to have both in the same WG, that wasn't my point, the point
is if there is a concrete reason that others aren't working on it, I wanted
to know why. There are JWPs, I don't know anything about them, but it
doesn't really matter if they have different approaches, different cryptos,
etc... Let's look at the features, that's at the core of what matters. So
far the only feature we've been able to nail down is *offline claim
transmission*. Will JWPs support *offline claim transmission*?

On Fri, Aug 5, 2022 at 11:55 AM Daniel Fett  wrote:

> It's not that the people I have spoken to didn't like the idea of SD-JWT.
> It's just on a different layer than JWPs, using a different approach,
> different crypto, providing different features, and on a different
> timeline. There's no compelling reason to have both in the same WG. There
> are nonetheless good reasons to have SD-JWT. Having SD-JWT in OAuth WG is
> not an attempt to "backdoor" anything in!
>
> I also didn't say that we should adopt SD-JWT because it has been
> implemented. You took my statement out of context. I wanted to underline
> that the spec is practically feature-complete and can be implemented today,
> providing the features promised. Meanwhile, JWP is not there yet.
>
> But, SD-JWT is not in production yet. If the OAuth WG decides that
> substantial changes are required, now is the best time for that.
>
> Also, I wanted to highlight with my statement that SD-JWT is easy to
> implement due to its simplicity.
>
> -Daniel
>
> Am 5. August 2022 11:28:49 MESZ schrieb Warren Parad  40rhosys...@dmarc.ietf.org>:
>>
>> Maybe they have a good reason for not wanting it, and then we shouldn't
>> be the WG that backdoor's it in. Also: "other people have already
>> implemented it" is a cognitive fallacy, so let's not use that as a
>> justification we have to make the standard.
>>
>> We should get a concrete reason why a WG that seems like the appropriate
>> one, thinks it wouldn't make sense. If it is just a matter of timing, then
>> whatever. But if there are concrete recommendations from that group, I
>> would love to hear them.
>>
>> On Fri, Aug 5, 2022 at 10:26 AM Daniel Fett > 40danielfett...@dmarc.ietf.org> wrote:
>>
>>> Am 05.08.22 um 10:22 schrieb Warren Parad:
>>>
>>> > and nobody involved in the JWP effort thinks that SD-JWT should be in
>>> that WG once created
>>>
>>> Why?
>>>
>>> For the reasons listed, I guess?
>>>
>>> Also, mind the "As far as I am aware" part, but I don't remember any
>>> discussions in that direction at IETF114.
>>>
>>> -Daniel
>>>
>>> ___
>>> 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

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

2022-08-05 Thread Daniel Fett

It's not that the people I have spoken to didn't like the idea of SD-JWT. It's 
just on a different layer than JWPs, using a different approach, different 
crypto, providing different features, and on a different timeline. There's no 
compelling reason to have both in the same WG. There are nonetheless good 
reasons to have SD-JWT. Having SD-JWT in OAuth WG is not an attempt to 
"backdoor" anything in!

I also didn't say that we should adopt SD-JWT because it has been implemented. 
You took my statement out of context. I wanted to underline that the spec is 
practically feature-complete and can be implemented today, providing the 
features promised. Meanwhile, JWP is not there yet.

But, SD-JWT is not in production yet. If the OAuth WG decides that substantial 
changes are required, now is the best time for that.

Also, I wanted to highlight with my statement that SD-JWT is easy to implement 
due to its simplicity. 

-Daniel

Am 5. August 2022 11:28:49 MESZ schrieb Warren Parad 
:
>Maybe they have a good reason for not wanting it, and then we shouldn't be
>the WG that backdoor's it in. Also: "other people have already implemented
>it" is a cognitive fallacy, so let's not use that as a justification we
>have to make the standard.
>
>We should get a concrete reason why a WG that seems like the appropriate
>one, thinks it wouldn't make sense. If it is just a matter of timing, then
>whatever. But if there are concrete recommendations from that group, I
>would love to hear them.
>
>On Fri, Aug 5, 2022 at 10:26 AM Daniel Fett 40danielfett...@dmarc.ietf.org> wrote:
>
>> Am 05.08.22 um 10:22 schrieb Warren Parad:
>>
>> > and nobody involved in the JWP effort thinks that SD-JWT should be in
>> that WG once created
>>
>> Why?
>>
>> For the reasons listed, I guess?
>>
>> Also, mind the "As far as I am aware" part, but I don't remember any
>> discussions in that direction at IETF114.
>>
>> -Daniel
>>
>> ___
>> 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

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

Maybe they have a good reason for not wanting it, and then we shouldn't be
the WG that backdoor's it in. Also: "other people have already implemented
it" is a cognitive fallacy, so let's not use that as a justification we
have to make the standard.

We should get a concrete reason why a WG that seems like the appropriate
one, thinks it wouldn't make sense. If it is just a matter of timing, then
whatever. But if there are concrete recommendations from that group, I
would love to hear them.

On Fri, Aug 5, 2022 at 10:26 AM Daniel Fett  wrote:

> Am 05.08.22 um 10:22 schrieb Warren Parad:
>
> > and nobody involved in the JWP effort thinks that SD-JWT should be in
> that WG once created
>
> Why?
>
> For the reasons listed, I guess?
>
> Also, mind the "As far as I am aware" part, but I don't remember any
> discussions in that direction at IETF114.
>
> -Daniel
>
> ___
> 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

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

2022-08-05 Thread Daniel Fett


Am 05.08.22 um 10:22 schrieb Warren Parad:
> and nobody involved in the JWP effort thinks that SD-JWT should be in that WG 
once created


Why?


For the reasons listed, I guess?

Also, mind the "As far as I am aware" part, but I don't remember any 
discussions in that direction at IETF114.


-Daniel

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

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

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

2022-08-05 Thread Daniel Fett

 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  *On
Behalf Of * Rifaat Shekh-Yusef
*Sent:* Thursday, July 28, 2022 8:17 PM
*To:* oauth 
        *Subject:* [OAUTH-WG] Call for adoption -

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

2022-08-04 Thread Jaimandeep Singh

t;>>>> (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  *On Behalf Of * Rifaat
>>>>> Shekh-Yusef
>>>>> *Sent:* Thursday, July 28, 2022 8:17 PM
>>>>> *To:* oauth 
>>>>> *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=05%7C01%7CKristina.Yasuda%40microsoft.com%7Ca2d72420ea2c40f2d7c908da70f7b388%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637946506426392735%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=d1EoHuRcBi40%2B1h1p5yZ28O7l8oq%2FibDewlJObT1Gwc%3D=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 list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

2022-08-04 Thread David Chadwick


  
  
Answers inline below

On 03/08/2022 14:57, Torsten
  Lodderstedt wrote:


  
  
  
  
Am 02.08.2022 um 19:30 schrieb David
  Chadwick :
  

  
  

  
  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

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

2022-08-03 Thread Torsten Lodderstedt

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

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

2022-08-03 Thread David Chadwick

r selective disclosure
using the issuer/holder/verifier pattern, including
those for ISO Mobile Driver's Licenses.

  



As far as I can see mobile driving licenses are the
  *only* concrete use case that has been mentioned so far.
  Did I miss one?


Given that the goal is to reproduce “the
user experience of presenting credentials in-person”,
  let’s look at one. My driving license lists the following
  information:


* a unique driver id (which itself encodes part of my
  name, dob, and a male/female bit)
* full name
* address
* date and country of birth
* license issuer, issued-at and expiry dates
* the categories of vehicle I’m entitled to drive


ISO mobile drivers’ licenses are supposed to be
  unlinkable so the driver ID is out. The expiry and
  issued-at probably shouldn’t be able to be selectively
  non-disclosed. So that only leaves 5 fields: full name,
  address, date of birth, country of birth, and categories
  of vehicle. 


So even if you issued a separate JWT for each field,
  that’s only 5 JWTs. Why is that not practical? 


— Neil


  

   
  That's why I support adoption.
   
    
-- Mike
   
  

  From: OAuth <oauth-boun...@ietf.org>
On Behalf Of 
Neil Madden
Sent: Tuesday, August 2, 2022 2:16 AM
To: Kristina Yasuda 40microsoft@dmarc.ietf.org>
Cc: oauth <oauth@ietf.org>
        Subject: Re: [OAUTH-WG] Call for adoption
- SD-JWT

  
   
   
  

  
On 2 Aug 2022, at 03:20,
  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 what’s the plan for
revocation in this scenario? Something like OCSP
Stapling? Short-lived tokens? Either way, the
client will need to go back to the issuer
regularly.


  


  

  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.

  


   


  I’m not sure why this would

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

2022-08-02 Thread Giuseppe De Marco

Hi Neil,

The problem of the linkability affects both sd-jwt (opaque values) and
traditional jwt (readable values).

Even if I present an mDL or an sd-jwt without disclosing any user attribute
in It, the linkability Is possible exploting the VC itself and its public
key, adopted as proof of possession of the vc. The public key won't change
in different vcs if the wallet has only a single  private Key to sign it's
issuance requests.

A salted/hashed value doesnt tell you anything about its content but Is
still linkable, because It won't change, It Will be presented and presented
again and due to this It is traceable and a user linkable over many
different RPs.

As we have the pairwised subject id in oidc, that changes in relations of
the audience, well, even with VCs we May enable the concept of ephemeral VC
(and ephemeral bounded public Key). A Citizen that doesnt want to be
tracked may ask for the issuance of a VC for each RP.

Without enabling the advanced crypto in our implementations, the
salted/hashed strategy seems like the only usable for selective disclosure
in several contexts, thus a good issuance strategy covers the privacy
requirements as well, so let's give a place for sd-jwt because we really
need It, otherwise we'll have a future painted in mDoc/CBOR and jwt would
not be considered as an usable data format. Dont let this happen!

Best

Il mer 3 ago 2022, 00:10 Neil Madden  ha scritto:

>
> On 2 Aug 2022, at 21:04, Mike Jones  wrote:
>
> 
>
> Neil, you wrote:
>
> "SD-JWT is not simpler. Anyway, I think I have learnt enough from this
> thread, we don’t have to keep arguing the same points. I think the claims
> of combinatorial explosion are somewhat exaggerated and I don’t see
> compelling evidence of a real world need for selective disclosure in OAuth,
> so I don’t support this draft."
>
>
>
> Speculatively issuing JWTs with combinations of claims because they might
> be used in the future might be a fine strawman proposal to score debating
> points but is hardly a practical engineering solution.
>
>
> Why would it be speculative?
>
>   Whereas SD-JWT meets the needs of JSON-based use cases for selective
> disclosure using the issuer/holder/verifier pattern, including those for
> ISO Mobile Driver's Licenses.
>
>
> As far as I can see mobile driving licenses are the *only* concrete use
> case that has been mentioned so far. Did I miss one?
>
> Given that the goal is to reproduce “the user experience of presenting
> credentials in-person”, let’s look at one. My driving license lists the
> following information:
>
> * a unique driver id (which itself encodes part of my name, dob, and a
> male/female bit)
> * full name
> * address
> * date and country of birth
> * license issuer, issued-at and expiry dates
> * the categories of vehicle I’m entitled to drive
>
> ISO mobile drivers’ licenses are supposed to be unlinkable so the driver
> ID is out. The expiry and issued-at probably shouldn’t be able to be
> selectively non-disclosed. So that only leaves 5 fields: full name,
> address, date of birth, country of birth, and categories of vehicle.
>
> So even if you issued a separate JWT for each field, that’s only 5 JWTs.
> Why is that not practical?
>
> — Neil
>
>
>
> That's why I support adoption.
>
>
>
>        -- Mike
>
>
>
> *From:* OAuth  *On Behalf Of * Neil Madden
> *Sent:* Tuesday, August 2, 2022 2:16 AM
> *To:* Kristina Yasuda 
> *Cc:* oauth 
> *Subject:* Re: [OAUTH-WG] Call for adoption - SD-JWT
>
>
>
>
>
> On 2 Aug 2022, at 03:20, 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 what’s the plan for revocation in this scenario? Something like OCSP
> Stapling? Short-lived tokens? Either way, the client will need to go back
> to the issuer regularly.
>
>
>
> 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.
>
>
>
> I’m not sure why this would be a goal. Presenting credentials in person is
> subject to many constraints that just don’t apply in the digital

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

2022-08-02 Thread Neil Madden


> On 2 Aug 2022, at 21:04, Mike Jones  wrote:
> 
> 
> Neil, you wrote:
> "SD-JWT is not simpler. Anyway, I think I have learnt enough from this 
> thread, we don’t have to keep arguing the same points. I think the claims of 
> combinatorial explosion are somewhat exaggerated and I don’t see compelling 
> evidence of a real world need for selective disclosure in OAuth, so I don’t 
> support this draft."
>  
> Speculatively issuing JWTs with combinations of claims because they might be 
> used in the future might be a fine strawman proposal to score debating points 
> but is hardly a practical engineering solution.

Why would it be speculative? 

>   Whereas SD-JWT meets the needs of JSON-based use cases for selective 
> disclosure using the issuer/holder/verifier pattern, including those for ISO 
> Mobile Driver's Licenses.

As far as I can see mobile driving licenses are the *only* concrete use case 
that has been mentioned so far. Did I miss one?

Given that the goal is to reproduce “the user experience of presenting 
credentials in-person”, let’s look at one. My driving license lists the 
following information:

* a unique driver id (which itself encodes part of my name, dob, and a 
male/female bit)
* full name
* address
* date and country of birth
* license issuer, issued-at and expiry dates
* the categories of vehicle I’m entitled to drive

ISO mobile drivers’ licenses are supposed to be unlinkable so the driver ID is 
out. The expiry and issued-at probably shouldn’t be able to be selectively 
non-disclosed. So that only leaves 5 fields: full name, address, date of birth, 
country of birth, and categories of vehicle. 

So even if you issued a separate JWT for each field, that’s only 5 JWTs. Why is 
that not practical? 

— Neil

>  
> That's why I support adoption.
>  
>-- Mike
>  
> From: OAuth  On Behalf Of Neil Madden
> Sent: Tuesday, August 2, 2022 2:16 AM
> To: Kristina Yasuda 
> Cc: oauth 
> Subject: Re: [OAUTH-WG] Call for adoption - SD-JWT
>  
>  
> On 2 Aug 2022, at 03:20, Kristina Yasuda 
>  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 what’s the plan for revocation in this scenario? Something like OCSP 
> Stapling? Short-lived tokens? Either way, the client will need to go back to 
> the issuer regularly.
> 
> 
> 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.
>  
> I’m not sure why this would be a goal. Presenting credentials in person is 
> subject to many constraints that just don’t apply in the digital world.
> 
> 
>  
> 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.
>  
> I’m not sure what any of this has to do with OAuth?
>  
>  
> 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 id

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

2022-08-02 Thread Mike Jones

Neil, you wrote:
"SD-JWT is not simpler. Anyway, I think I have learnt enough from this thread, 
we don’t have to keep arguing the same points. I think the claims of 
combinatorial explosion are somewhat exaggerated and I don’t see compelling 
evidence of a real world need for selective disclosure in OAuth, so I don’t 
support this draft."

Speculatively issuing JWTs with combinations of claims because they might be 
used in the future might be a fine strawman proposal to score debating points 
but is hardly a practical engineering solution.  Whereas SD-JWT meets the needs 
of JSON-based use cases for selective disclosure using the 
issuer/holder/verifier pattern, including those for ISO Mobile Driver's 
Licenses.

That's why I support adoption.

   -- Mike

From: OAuth  On Behalf Of Neil Madden
Sent: Tuesday, August 2, 2022 2:16 AM
To: Kristina Yasuda 
Cc: oauth 
Subject: Re: [OAUTH-WG] Call for adoption - SD-JWT


On 2 Aug 2022, at 03:20, Kristina Yasuda 
mailto: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 what’s the plan for revocation in this scenario? Something like OCSP 
Stapling? Short-lived tokens? Either way, the client will need to go back to 
the issuer regularly.


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.

I’m not sure why this would be a goal. Presenting credentials in person is 
subject to many constraints that just don’t apply in the digital world.



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.

I’m not sure what any of this has to do with OAuth?


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…

The same is needed in SD-JWT - the wallet needs to manage pairwise identifiers 
and which subset of claims to disclose.



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.

Being over 65 also proves that you are over 21.


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.

SD-JWT is not simpler. Anyway, I think I have learnt enough from this thread, 
we don’t have to keep arguing the same points. I think the claims of 
combinatorial explosion are somewhat exaggerated and I don’t see compelling 
evidence of a real world need for selective disclosure in OAuth, so I

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

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/
  
  
   
  
  
  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

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


  
  
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
 On Behalf Of 
Warren Parad
Sent: Tuesday, August 2, 2022 7:56 AM
To: David Chadwick

Cc: oauth 
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,

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


  
  


On 02/08/2022 12:56, Warren Parad
  wrote:


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

Only if the user subsequently wants to use the VC offline and
  only disclose part of it. Then there is value in having a SD-JWT
  with blinded properties
kind regards
David


  
On Tue, Aug 2, 2022, 13:39
  David Chadwick 
  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 
  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

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

2022-08-02 Thread Kristina Yasuda

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  On Behalf Of Warren Parad
Sent: Tuesday, August 2, 2022 7:56 AM
To: David Chadwick 
Cc: oauth 
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 
mailto: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 
mailto: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 
mailto: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

https://github.com/oauthstuff/draft-selective-disclosure-jwt/pull/124<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Foauthstuff%2Fdraft-selective-disclosure-jwt%2Fpull%2F124=05%7C01%7CKristina.Yasuda%40microsoft.com%7Cba54d47e26fe4d35c4ce08da7

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
>>>
>>> https://github.com/oauthstuff/draft-selective-disclosure-jwt/pull/124
>>>
>>> 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

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


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

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

2022-08-02 Thread Jaromir Talir

On Tue, 2022-08-02 at 12:02 +0200, Torsten Lodderstedt wrote:
> 
> 
> > Am 02.08.2022 um 11:44 schrieb David Chadwick
> > :
> > 
> >  
> > 
> > On 01/08/2022 18:39, Warren Parad wrote:
> >  
> > > So the question is how many offline interactions are there, and
> > > what do those look like? 
> > 
> > This to me is the key question. If the vast majority of
> > transactions between the user/wallet and the RP are online (which I
> > believe that most will be), then the client/wallet/user can request
> > a short lived credential on demand from the RS containing just the
> > claims that the RP is requesting. The same access token should be
> > usable for this. This also solves the pair-wise ID issue between
> > the wallet/user and the RP, as the user's key inserted into the
> > credential will be ephemeral.
> > 
> 
> That is certainly feasible and it would solve selective disclosure
> and unlinkability on the RP side. 
> 
> However, it comes at a price. It will tell the issuer a lot about the
> frequency, the time, and the claims a user uses for accessing
> service, degrading privacy towards issuers.
> 
> That’s the reason I would not expect a lot of deployments to embrace
> this pattern. e.g. I would doubt eIDAS 2 goes that way.     

Agree. It definitely doesn't go this way. Here is citation from
regulation proposal:
"Wallet shall ensure that trust service providers of qualified
attestations of attributes cannot receive any information about the use
of these attributes"
http://timspeelman.nl/eidas/#A6a(4)(b)

I could also use another citation:
"Wallet shall enable user to securely request and obtain, store,
SELECT, combine and share, in a manner that is transparent to and
traceable by the user, the necessary legal person identification data
and electronic attestation of attributes to authenticate online and
offline in order to use online public and private services"
http://timspeelman.nl/eidas/#A6a(3)(a)

To emphasize this, regarding discussion whether there are use cases for
SD-JWT or not - there are 27 member states of EU that are working on
regulation where it looks like SD-JWT fits it's requirements. 

> > For those (possible few) transactions in which the wallet is
> > offline, then the wallet has to obtain the (possibly selectively
> > disclosed) credential before it is needed. But this is already the
> > case today with boarding passes. I load it onto my phone whilst I
> > am online at home, and then I present it offline at the airport
> > e.g. via a QR code. So using this model the user can go to the RS
> > when online, obtain a short lived selectively disclosed credential
> > that they know will be needed later (e.g. age over 18 for entering
> > a nightclub) and then present it offline when they arrive at the
> > nightclub.
> > For those (possibly even fewer) transactions in which the user is
> > suddenly caught offline e.g. on the top of a mountain by a police
> > officer, then I can see that the SD-JWT with blinded property names
> > and values is a suitable solution. The user might have a few of
> > these in their wallet, each being one-time use with a different
> > key, that once selectively disclosed are discarded. The user/wallet
> > can refresh the store periodically (or the wallet could do this
> > automatically ensuring that a small number are always present).
> > These would also need to be relatively short lived otherwise a
> > revocation mechanism would need to be introduced (horror of
> > horrors, especially on the top of a mountain with no access to the
> > revocation list).
> > Kind regards
> > David
> > ___
> > 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

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

2022-08-02 Thread Pieter Kasselman

I support adoption

From: OAuth  On Behalf Of Rifaat Shekh-Yusef
Sent: Friday, July 29, 2022 1:17 AM
To: oauth 
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=05%7C01%7Cpieter.kasselman%40microsoft.com%7Cb92f737c857748f967d408da70f7b013%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637946506395768213%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=A2ksGIpHDgpdKbxwcLJvX3px2TVSN6nZ4V7E3DOefXo%3D=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

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



> Am 02.08.2022 um 11:44 schrieb David Chadwick 
> :
> 
> 
> 
> On 01/08/2022 18:39, Warren Parad wrote:
>> So the question is how many offline interactions are there, and what do 
>> those look like?
> This to me is the key question. If the vast majority of transactions between 
> the user/wallet and the RP are online (which I believe that most will be), 
> then the client/wallet/user can request a short lived credential on demand 
> from the RS containing just the claims that the RP is requesting. The same 
> access token should be usable for this. This also solves the pair-wise ID 
> issue between the wallet/user and the RP, as the user's key inserted into the 
> credential will be ephemeral.
> 
> 

That is certainly feasible and it would solve selective disclosure and 
unlinkability on the RP side. 

However, it comes at a price. It will tell the issuer a lot about the 
frequency, the time, and the claims a user uses for accessing service, 
degrading privacy towards issuers. 

That’s the reason I would not expect a lot of deployments to embrace this 
pattern. e.g. I would doubt eIDAS 2 goes that way. 
> For those (possible few) transactions in which the wallet is offline, then 
> the wallet has to obtain the (possibly selectively disclosed) credential 
> before it is needed. But this is already the case today with boarding passes. 
> I load it onto my phone whilst I am online at home, and then I present it 
> offline at the airport e.g. via a QR code. So using this model the user can 
> go to the RS when online, obtain a short lived selectively disclosed 
> credential that they know will be needed later (e.g. age over 18 for entering 
> a nightclub) and then present it offline when they arrive at the nightclub.
> 
> For those (possibly even fewer) transactions in which the user is suddenly 
> caught offline e.g. on the top of a mountain by a police officer, then I can 
> see that the SD-JWT with blinded property names and values is a suitable 
> solution. The user might have a few of these in their wallet, each being 
> one-time use with a different key, that once selectively disclosed are 
> discarded. The user/wallet can refresh the store periodically (or the wallet 
> could do this automatically ensuring that a small number are always present). 
> These would also need to be relatively short lived otherwise a revocation 
> mechanism would need to be introduced (horror of horrors, especially on the 
> top of a mountain with no access to the revocation list).
> 
> Kind regards
> 
> David
> 
> ___
> 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

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

.
>>>>>
>>>>>
>>>>>
>>>>> 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  *On Behalf Of * Rifaat
>>>>> Shekh-Yusef
>>>>> *Sent:* Thursday, July 28, 2022 8:17 PM
>>>>> *To:* oauth 
>>>>> *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=05%7C01%7CKristina.Yasuda%40microsoft.com%7Ca2d72420ea2c40f2d7c908da70f7b388%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637946506426392735%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=d1EoHuRcBi40%2B1h1p5yZ28O7l8oq%2FibDewlJObT1Gwc%3D=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 list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

sed 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 mailto:oauth-boun...@ietf.org>> On 
>>>> Behalf Of Rifaat Shekh-Yusef
>>>> Sent: Thursday, July 28, 2022 8:17 PM
>>>> To: oauth mailto: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=05%7C01%7CKristina.Yasuda%40microsoft.com%7Ca2d72420ea2c40f2d7c908da70f7b388%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637946506426392735%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=d1EoHuRcBi40%2B1h1p5yZ28O7l8oq%2FibDewlJObT1Gwc%3D=0>
>>>>  
>>>> 
>>>> Please, provide your feedback on the mailing list by August 12th.
>>>> 
>>>>  
>>>> 
>>>> Regards,
>>>> 
>>>>  Rifaat & Hannes
>>>> 
>>>>  
>>>> 
>>>> ___
>>>> OAuth mailing list
>>>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>>>> https://www.ietf.org/mailman/listinfo/oauth 
>>>> <https://www.ietf.org/mailman/listinfo/oauth>
>>>> ___
>>>> OAuth mailing list
>>>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>>>> https://www.ietf.org/mailman/listinfo/oauth 
>>>> <https://www.ietf.org/mailman/listinfo/oauth>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth 
>> <https://www.ietf.org/mailman/listinfo/oauth>

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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


  
  


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

So
  the question is how many offline interactions are there, and what
  do those look like? 
This to me is the key question. If the vast majority of
  transactions between the user/wallet and the RP are online (which
  I believe that most will be), then the client/wallet/user can
  request a short lived credential on demand from the RS containing
  just the claims that the RP is requesting. The same access token
  should be usable for this. This also solves the pair-wise ID issue
  between the wallet/user and the RP, as the user's key inserted
  into the credential will be ephemeral.
For those (possible few) transactions in which the wallet is
  offline, then the wallet has to obtain the (possibly selectively
  disclosed) credential before it is needed. But this is already the
  case today with boarding passes. I load it onto my phone whilst I
  am online at home, and then I present it offline at the airport
  e.g. via a QR code. So using this model the user can go to the RS
  when online, obtain a short lived selectively disclosed credential
  that they know will be needed later (e.g. age over 18 for entering
  a nightclub) and then present it offline when they arrive at the
  nightclub.
For those (possibly even fewer) transactions in which the user is
  suddenly caught offline e.g. on the top of a mountain by a police
  officer, then I can see that the SD-JWT with blinded property
  names and values is a suitable solution. The user might have a few
  of these in their wallet, each being one-time use with a different
  key, that once selectively disclosed are discarded. The
  user/wallet can refresh the store periodically (or the wallet
  could do this automatically ensuring that a small number are
  always present). These would also need to be relatively short
  lived otherwise a revocation mechanism would need to be introduced
  (horror of horrors, especially on the top of a mountain with no
  access to the revocation list).

Kind regards
David

  


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

2022-08-02 Thread Neil Madden


> On 2 Aug 2022, at 03:20, Kristina Yasuda 
>  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 what’s the plan for revocation in this scenario? Something like OCSP 
Stapling? Short-lived tokens? Either way, the client will need to go back to 
the issuer regularly.

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

I’m not sure why this would be a goal. Presenting credentials in person is 
subject to many constraints that just don’t apply in the digital world.

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

I’m not sure what any of this has to do with OAuth?
 
>  
> 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…

The same is needed in SD-JWT - the wallet needs to manage pairwise identifiers 
and which subset of claims to disclose.

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

Being over 65 also proves that you are over 21.

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

SD-JWT is not simpler. Anyway, I think I have learnt enough from this thread, 
we don’t have to keep arguing the same points. I think the claims of 
combinatorial explosion are somewhat exaggerated and I don’t see compelling 
evidence of a real world need for selective disclosure in OAuth, so I don’t 
support this draft.

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

— Neil___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

e 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 >> 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 simple

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

f 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 
>>>>>>  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  On Behalf Of Rifaat Shekh-Yusef
>>>>>> Sent: Thursday, July 28, 2022 8:17 PM
>>>>>> To: oauth 
>>>>>> 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/
>>>>>> 
>>>>>>  
>>>>>> 
>>>>>> 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 list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

lection 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  *On Behalf Of * Rifaat
>>> Shekh-Yusef
>>> *Sent:* Thursday, July 28, 2022 8:17 PM
>>> *To:* oauth 
>>> *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=05%7C01%7CKristina.Yasuda%40microsoft.com%7Ca2d72420ea2c40f2d7c908da70f7b388%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637946506426392735%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=d1EoHuRcBi40%2B1h1p5yZ28O7l8oq%2FibDewlJObT1Gwc%3D=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

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

act 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  On Behalf Of Rifaat Shekh-Yusef
>>>> Sent: Thursday, July 28, 2022 8:17 PM
>>>> To: oauth 
>>>> 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/
>>>> 
>>>>  
>>>> 
>>>> 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

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

o 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  On Behalf Of Rifaat Shekh-Yusef
>>>> Sent: Thursday, July 28, 2022 8:17 PM
>>>> To: oauth 
>>>> 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/
>>>> 
>>>>  
>>>> 
>>>> 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

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

;
>>
>>
>>
>> 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  *On Behalf Of * Rifaat Shekh-Yusef
>> *Sent:* Thursday, July 28, 2022 8:17 PM
>> *To:* oauth 
>> *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=05%7C01%7CKristina.Yasuda%40microsoft.com%7Ca2d72420ea2c40f2d7c908da70f7b388%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637946506426392735%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=d1EoHuRcBi40%2B1h1p5yZ28O7l8oq%2FibDewlJObT1Gwc%3D=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

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

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  On Behalf Of Rifaat Shekh-Yusef
>> Sent: Thursday, July 28, 2022 8:17 PM
>> To: oauth 
>> 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/
>> 
>>  
>> 
>> 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

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

If we are in a offline scenario how does the verifier got ahold of the
public key associated with the id token?

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.


On Tue, Aug 2, 2022, 04:21 Kristina Yasuda  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  *On Behalf Of * Rifaat Shekh-Yusef
> *Sent:* Thursday, July 28, 2022 8:17 PM
> *To:* oauth 
> *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=05%7C01%7CKristina.Yasuda%40microsoft.com%7Ca2d72420ea2c40f2d7c908da70f7b388%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637946506426392735%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7

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

2022-08-01 Thread Kristina Yasuda

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  On Behalf Of Rifaat Shekh-Yusef
Sent: Thursday, July 28, 2022 8:17 PM
To: oauth 
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=05%7C01%7CKristina.Yasuda%40microsoft.com%7Ca2d72420ea2c40f2d7c908da70f7b388%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637946506426392735%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=d1EoHuRcBi40%2B1h1p5yZ28O7l8oq%2FibDewlJObT1Gwc%3D=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

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

2022-08-01 Thread Vittorio Bertocci

I support adoption of this draft as a WG document.

On Thu, Jul 28, 2022 at 5:17 PM Rifaat Shekh-Yusef 
wrote:

> *This message originated outside your organization.*
>
> --
>
> All,
>
> This is a call for adoption for the *SD-JWT* document
> https://datatracker.ietf.org/doc/draft-fett-oauth-selective-disclosure-jwt/
> 
>
> 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

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

2022-08-01 Thread Warren Parad

And in the situation they did, we would just use the existing scopes and
let the user approve the selected list. RS requests, AS redirects the user,
the user approves. (RS => AS => User)

The draft isn't trying to prevent needing to do that, it's trying to change
the order of the flow, first the AS, then the user, then the RS (AS => User
=> RS).

The only reason I can see doing this is if there are going to be guaranteed
offline interactions, either the AS is offline or the user is offline.

   - The AS offline is an interesting side journey. What if your country is
   taken over and the AS is really forever offline. This draft isn't going to
   fix that because the tokens expire. So unless the goal is to create never
   expiring tokens, it isn't a solution. And worse since we know attributes
   about a user do change over time, they'll have to be updatable. With the
   current draft we just update the AS and generate a new token, we can't do
   that if the AS is offline.


So the question is how many offline interactions are there, and what do
those look like? We know we are incorrectly over-engineering here if there
are only a small set of them. If there are many of these, then it makes
sense to continue down the path of "this is how we solve for the User
offline".

On Mon, Aug 1, 2022 at 7:26 PM Neil Madden 
wrote:

>
> On 1 Aug 2022, at 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.
>
>
> But this isn’t true. As I said on the other thread on the JOSE list, the
> client doesn’t need to go back to the AS to get a new token with JWTs
> anymore than they do with SD-JWT. In the limit the AS could issue a
> separate JWT for each claim and then the client can choose which ones to
> send to the RS.
>
> Now of course if the AS actually issued a JWT for each claim that would be
> very inefficient. But in reality the client is not going to want a totally
> unique combination of claims for each presentation. There are likely just a
> small handful of sets of claims that actually make sense to disclose
> together in any scenario, so the AS could issue a small number of JWTs that
> cover those scenarios. Indeed, if the client is producing unique
> combinations of claims for a presentation then that provides a way to
> fingerprint that client/user!
>
> So far I’ve failed to see any convincing scenario where a client would
> really need such fine-grained control over selective disclosure.
>
> — Neil
>
>
> 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
>>
>> https://github.com/oauthstuff/draft-selective-disclosure-jwt/pull/124
>>
>> 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

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

2022-08-01 Thread Neil Madden

> On 1 Aug 2022, at 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. 

But this isn’t true. As I said on the other thread on the JOSE list, the client 
doesn’t need to go back to the AS to get a new token with JWTs anymore than 
they do with SD-JWT. In the limit the AS could issue a separate JWT for each 
claim and then the client can choose which ones to send to the RS. 

Now of course if the AS actually issued a JWT for each claim that would be very 
inefficient. But in reality the client is not going to want a totally unique 
combination of claims for each presentation. There are likely just a small 
handful of sets of claims that actually make sense to disclose together in any 
scenario, so the AS could issue a small number of JWTs that cover those 
scenarios. Indeed, if the client is producing unique combinations of claims for 
a presentation then that provides a way to fingerprint that client/user!

So far I’ve failed to see any convincing scenario where a client would really 
need such fine-grained control over selective disclosure. 

— Neil

> 
>> On Mon, Aug 1, 2022 at 9:22 AM David Chadwick 
>>  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
>>> 
>>> https://github.com/oauthstuff/draft-selective-disclosure-jwt/pull/124
>>> 
>>> 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 
>>>  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

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

2022-08-01 Thread Warren Parad

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
>>
>> https://github.com/oauthstuff/draft-selective-disclosure-jwt/pull/124
>>
>> 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
>>>

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


  
  
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 
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
  
  
  https://github.com/oauthstuff/draft-selective-disclosure-jwt/pull/124
  
  
  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 
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).

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

2022-08-01 Thread Aaron Parecki

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
>
> https://github.com/oauthstuff/draft-selective-disclosure-jwt/pull/124
>
> 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 <
>>

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


  
  
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


https://github.com/oauthstuff/draft-selective-disclosure-jwt/pull/124


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

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

2022-08-01 Thread Giuseppe De Marco

Hi David,

This issue was already raised.
Below the proposal for both draft and python code

https://github.com/oauthstuff/draft-selective-disclosure-jwt/pull/124

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

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


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

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

2022-08-01 Thread Warren Parad

>
> 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  40pingidentity@dmarc.ietf.org> wrote:
>
>> I support adoption.
>>
>> On Thu, Jul 28, 2022, 8:17 PM Rifaat Shekh-Yusef 
>> wrote:
>>
>>> All,
>>>
>>> This is a call for

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