Internet-Draft draft-ietf-oauth-resource-metadata-01.txt is now available. It
is a work item of the Web Authorization Protocol (OAUTH) WG of the IETF.
Title: OAuth 2.0 Protected Resource Metadata
Authors: Michael B. Jones
Phil Hunt
Aaron Parecki
Name:
Hi Denis,
you address me directly in this message, but there is not much in there I’d
care to reply to.
However, some people might believe what you are saying here:
> On 16. Oct 2023, at 15:24, Denis wrote:
>
> Structures can be generated using CDDL, but can't be validated
> against CDDL.
Hi all,
The authors have finished incorporating the changes discussed at the last
meeting and published a new draft:
https://www.ietf.org/archive/id/draft-parecki-oauth-first-party-apps-00.html
Highlights include:
• Renamed "device_session" to "auth_session" (feel free to continue
bikeshedding
Hi all,
Here is the updated Transaction Tokens draft, which is on the agenda for
Prague. In the new draft, we have incorporated the feedback received in
IETF 117, as well as removed the "Nested Transaction Tokens" part. Salient
points are:
1. Transaction Tokens now have separate claims for:
> On Oct 13, 2023, at 6:57 PM, Orie Steele wrote:
>
>
> riffing on this, if it's possible to use a "simple and safe parser on the
> untrusted data", before using a "maybe safe / probably fast " parser on the
> trusted data, maybe do that : )
>
>> This is also not dissimilar to additional
Agree that it should be clarified. Being precise with language around this
stuff is tricky. But my understanding of the intent was to ensure that no
digest value is repeated in the whole of the SD-JWT - either in the payload
directly or recursively in any Disclosure. Because of the trickiness of
That's a much better place to communicate redaction reasons.
Although if the use case for communicating secured redaction reasons from
the holder to the verifier doesn't fit well with SD-JWT spec, it's possible
that's a profile specific thing, where interoperability matters less, so it
should be
Hi Daniel,
Thanks for the response, that makes total sense.
Jacob
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
The Holder can put such information into the KB-JWT, if required.
-Daniel
Am 20.10.23 um 16:28 schrieb Orie Steele:
In some ways this is related to the question about disclosures.
On Fri, Oct 20, 2023 at 9:03 AM Daniel Fett
wrote:
At least at the moment I don't think that there is a
In some ways this is related to the question about disclosures.
On Fri, Oct 20, 2023 at 9:03 AM Daniel Fett wrote:
> At least at the moment I don't think that there is a huge need for such a
> feature. I don't think that we should clutter the existing SD-JWT data
> structures with such
Hi Jacob,
the intention was to cover the first case you listed. We should clarify
this.
-Daniel
Am 20.10.23 um 15:02 schrieb Jacob Ward:
Hello again,
On a similar note to my previous email, could I get some clarity on a
step in the SD-JWT verification process?
/4. If any digests were
Hi Jacob,
this check is mainly important for the Holder to ensure the integrity of
the received SD-JWT. For the Verifier, there is not much to gain by
checking this (but it also doesn't hurt either).
However, we intended to keep the algorithms for the Holder and Verifier
similar and
At least at the moment I don't think that there is a huge need for such
a feature. I don't think that we should clutter the existing SD-JWT data
structures with such information.
If required, it could go into a separate data structure in the SD-JWT,
for example a list of JSON pointers with a
Hello again,
On a similar note to my previous email, could I get some clarity on a step
in the SD-JWT verification process?
*4. If any digests were found more than once in the previous step, the
SD-JWT MUST be rejected.*
Step 4 in Section 6.1 (as shown above) could have multiple meanings in my
Hello all,
Please let me know if there's a better channel to ask questions and/or
raise issues with the SD-JWT spec.
Currently as part of verification of an SD-JWT the following is stated:
*Upon receiving an SD-JWT, a Holder or a Verifier MUST ensure that *
- *the Issuer-signed JWT is
15 matches
Mail list logo
