[OAUTH-WG] Re: Second WGLC for Token Status List

[Dean Saxe]

 WG Chairs,

I support moving this draft forward.

Thanks,
-dhs
--
Dean H. Saxe, CIDPRO  (he/him)
Principal Engineer
Office of the CTO
Beyond Identity
dean.s...@beyondidentity.com




On Apr 7, 2025 at 11:10:03 PM, Steffen Schwalm 
wrote:

> Fully agree to Denis. Recommend to do the changes before publication
>
>
>
> *Von:* Denis 
> *Gesendet:* Montag, 7. April 2025 21:20
> *An:* Steffen Schwalm ; Kristina Yasuda <
> yasudakrist...@gmail.com>; ANTHONY NADALIN 
> *Cc:* torsten=40lodderstedt@dmarc.ietf.org; oauth 
> *Betreff:* Re: [OAUTH-WG] Re: Second WGLC for Token Status List
>
>
>
> *Caution:* This email originated from outside of the organization.
> Despite an upstream security check of attachments and links by Microsoft
> Defender for Office, a residual risk always remains. Only open attachments
> and links from known and trusted senders.
>
> I took a closer look to the document. Below are 17 comments.
>
>
>
>
>
> 1. The current definition of a Status List is:
>
>
>
>Status List:  An object in JSON or CBOR representation containing a 
> compressed byte array that represents the statuses of many Referenced Tokens.
>
>
>
> This definition is ambiguous. It is proposed to change this definition as 
> follows:
>
>
>
>Status List:  An object in JSON or CBOR representation containing a 
> compressed byte array itself contained in a Status List Token that represents 
> the statuses of many Referenced Tokens.
>
>
>
>
>
> 2. In section 4.1:
>
>
>
>3.  The Status Issuer sets the status values for all Referenced tokens 
> within the byte array.
>
>
>
> This sentence is ambiguous;.
>
>
>
> Change into:
>
>
>
>3.  The Status Issuer sets the status values for all Referenced Tokens 
> that are referenced in the Status List Token.
>
>
>
>
>
> 3. Section 5 states:
>
>
>
> Status List Token
>
>
>
>A Status List Token embeds *the* Status List into a token that is 
> cryptographically signed and protects the integrity of the Status  List.
>
>
>
> It would be more appropriate to use "a" instead of "the" and to say:
>
>
>
>A Status List Token embeds *a* Status List into a token that is 
> cryptographically signed and protects the integrity of the Status List.
>
>
>
>
>
> 4. Section 7.1 is stating:
>
>
>
> Status Types Values
>
>
>
>*  0x02 - "SUSPENDED" - The status of the Referenced Token is temporarily 
> invalid, hanging, debarred from privilege. This state is reversible.
>
>
>
> I would be worth to explain what is meant by " This state is reversible".
>
>
>
> Change into:
>
>
>
> This state is usually temporary. In a further issued Status List Token, this 
> state may remain the same, change to VALID, INVALID or to any other state.
>
>
>
>
>
> 5. Section 8.4, second paragraph states:
>
>
>
>To obtain the Status List Token, the *Relying Party* MUST send an HTTP
>
>
>
> The Holder can also obtain a Status List Token. Using the term" client" would 
> cover both cases.
>
>
>
> Change into:
>
>
>
>To obtain the Status List Token, the *client* UST send an HTTP
>
>
>
>
>
> 6. Section 9 states:
>
>
>
> Status List Aggregation
>
>
>
> Status List Aggregation is an optional mechanism to retrieve a list of 
> URIs to all Status List Tokens, allowing a *Relying Party* to fetch
>
> all relevant Status Lists for a specific type of Referenced Token or 
> Issuer.
>
>
>
> The concept of a *specific type of Referenced Token* looks odd, as the "type" 
> of the Referenced Token is not present in the Status List.
>
>
>
> I have not yet understood how a *client *can fetch "all relevant Status List 
> Tokens for a specific type of Referenced Token".
>
>
>
> I can understand how a how a *client *can fetch "all relevant Status List 
> Tokens for a specific Issuer".
>
> "The Status List Aggregation URI provides a list of Status List URIs."
>
>
>
> I would expect that it contains a list of Status List Token URIs, i.e. NOT a 
> list of Status List URIs.
>
>
>
> If all the URIs of the Status List Tokens of a given Issuer are made publicly 
> available, then there is a leakage of information.
>
> The client would be able to know roughly how many Referenced Tokens are 
> currently issued. Issuers should be warned of the consequences.
>
> This should be mentioned here as well as in the privacy considerations section
>
>
>
>
>
> 7. Section 12.5.2 states
>
>
>
> Colluding Status Issuer and Relying Party
>
>
>
>A Status Issuer and a Relying Party Issuer may link two transaction*s* 
> involving the same Referenced Tokens by comparing the status claims
>
>of the Referenced Token and therefore determine that they have interacted 
> with the same Holder.  It is therefore recommended to use
>
>Status Lists for Referenced Token formats that have similar unlinkability 
> properties.
>
>
>
> This section is not understandable to me. Would it be possible first to 
> explain how the link may happen only by using the SLT ?
>
>
>
> What means "similar unlinkability properties" 

[OAUTH-WG] [IANA #1416059] expert review for draft-ietf-oauth-selective-disclosure-jwt (media-type-structured-suffix)

[David Dong via RT]

Dear Alexey Melnikov, Darrel Miller (cc: oauth WG),

Following up on this; as the designated experts for the Structured Syntax 
Suffixes registry, can you review the proposed registration in 
draft-ietf-oauth-selective-disclosure-jwt-17 for us? Please see:

https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/

The due date is April 16th.

If this is OK, when the IESG approves the document for publication, we'll make 
the registration at:

https://www.iana.org/assignments/media-type-structured-suffix/

Unless you ask us to wait for the other reviewer, we’ll act on the first 
response we receive.

With thanks,

David Dong
IANA Services Sr. Specialist

On Tue Apr 08 12:13:03 2025, bcampb...@pingidentity.com wrote:
> Thanks David,
> 
> Just to try and connect the dots on the various pieces here - this is
> the
> same Structured Syntax Suffixes request as the last item in [media-
> types]
> draft-ietf-oauth-selective-disclosure-jwt media types and structured
> syntax
> suffix and registration review request
>  types/IzAcggxgUUlH64bzgk0WN6yB16U/>.
> 
> 
> On Wed, Apr 2, 2025 at 2:16 PM David Dong via RT <
> drafts-expert-review-comm...@iana.org> wrote:
> 
> > Dear Alexey Melnikov, Darrel Miller (cc: oauth WG),
> >
> > As the designated experts for the Structured Syntax Suffixes
> > registry, can
> > you review the proposed registration in
> > draft-ietf-oauth-selective-disclosure-jwt-17 for us? Please see:
> >
> > https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-
> > disclosure-jwt/
> >
> > The due date is April 16th.
> >
> > If this is OK, when the IESG approves the document for publication,
> > we'll
> > make the registration at:
> >
> > https://www.iana.org/assignments/media-type-structured-suffix/
> >
> > Unless you ask us to wait for the other reviewer, we’ll act on the
> > first
> > response we receive.
> >
> > With thanks,
> >
> > David Dong
> > IANA Services Sr. Specialist
> >
> > ___
> > OAuth mailing list -- oauth@ietf.org
> > To unsubscribe send an email to oauth-le...@ietf.org
> >

___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org