Hi Watson, We tried to bring your points into the OAuth interim meeting. Here my attempt to reflect the major parts of the discussion that happened there and the perspective from the editors: The allocation of status types in the registry has implications, and Idon't think they are the right ones.
Mike, Yaron, and myself received an email reporting a number of
vulnerabilities in JWT libraries (see below), and a number of suggested
mitigations Yaron has filed in his repo as issues:
https://github.com/yaronf/draft-sheffer-oauth-rfc8725bis/issues
This has prompted us to start a new draft for
Internet-Draft draft-ietf-oauth-selective-disclosure-jwt-15.txt is now
available. It is a work item of the Web Authorization Protocol (OAUTH) WG of
the IETF.
Title: Selective Disclosure for JWTs (SD-JWT)
Authors: Daniel Fett
Kristina Yasuda
Brian Campbell
Name:
Here are the comments on my AD review of this draft. Most of them will be
easy to fix, except for the normative references to changeable standards:
General: There are more than a couple of Normative references that are
pointing to 'living documents'. From my reading of the draft these
include:
>
> Section 11: RFC6819 is a normative reference, but it is Informational.
> We need to call that out in the IETF Last Call, and I have to approve the
> downref (which I will do).
Looking at the text in the document that references this RFC, it does not
look like any of these references are norm
Brian,
I'm glad we've finally reached rough consensus on adding the paragraph
I've wanted since SF, and more importantly highlighting the issues
that the security failures of SD-JWT makes for users.
However, the editorial issues with the verbosity of the privacy
considerations remains, and has go
RAR does not define it's equivalent of RFC 6750's "insufficient_scope"
error response (could be "insufficient_authorization", for example). Is
this intentional? If not, would it make sense to define it in a separate
document?
Dmitry
___
OAuth mailing lis
insufficient_scope
The request requires higher privileges than provided by the
access token. The resource server SHOULD respond with the HTTP
403 (Forbidden) status code and MAY include the "scope"
attribute with the scope necessary to access the protec
Thanks, I'm working on tracking down stable references for these and will
have a new version published addressing this feedback shortly.
Aaron
On Thu, Jan 16, 2025 at 6:54 AM Rifaat Shekh-Yusef
wrote:
> Section 11: RFC6819 is a normative reference, but it is Informational.
>> We need to call
Hi all,
We are pleased to announce that draft *-*15 of SD-JWT has been published
and is now available. Notable changes in this revision include some
additions and adjustments to privacy considerations based on Watson's
suggestions and addressing review comments from our AD resulting from her
evalu
On Thu, Jan 16, 2025 at 12:49 AM Christian Bormann wrote:
>
> Hi Watson,
>
>
>
> We tried to bring your points into the OAuth interim meeting. Here my attempt
> to reflect the major parts of the discussion that happened there and the
> perspective from the editors:
Thanks and sorry to have comp
11 matches
Mail list logo
