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 <Kristina.Yasuda=
40microsoft.com@dmarc.ietf.org> 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 <oauth-bounces@ietf.org> de la part de Warren Parad <wparad=
> 40rhosys.ch@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 <mail=
> 40danielfett.de@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 <wparad=
>> 40rhosys.ch@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 <fett=
>>> 40danielfett.de@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
>>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=05%7C01%7CKristina.Yasuda%40microsoft.com%7C03ac1c4a32f6457e128a08da76ccd39d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637952919372957096%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=aiBKf9gkCbDEgNPVKHWFPABIHS1s9rSrwSSI%2FVDLmuA%3D&reserved=0>
>>>>
>>> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>