[OAUTH-WG] [Technical Errata Reported] RFC7591 (7782)

[RFC Errata System]

The following errata report has been submitted for RFC7591,
"OAuth 2.0 Dynamic Client Registration Protocol".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7782

--
Type: Technical
Reported by: Tim Würtele 

Section: 3.2.1

Original Text
-
client_id
  REQUIRED.  OAuth 2.0 client identifier string.  It SHOULD NOT be
  currently valid for any other registered client, though an
  authorization server MAY issue the same client identifier to
  multiple instances of a registered client at its discretion.

Corrected Text
--
client_id
  REQUIRED.  OAuth 2.0 client identifier string.  It MUST NOT be
  currently valid for any other registered client, though an
  authorization server MAY issue the same client identifier to
  multiple instances of a registered client at its discretion.

Notes
-
Allowing the same client_id for multiple clients is a contradiction to:

1. This document, Section 1.3, (D), 2nd bullet point: "a client identifier that 
is unique at the server"

2. This document, Section 3.1: "The authorization server assigns this client a 
unique client identifier"

3. (normative reference) RFC 6749, Section 2.2: "The authorization server 
issues the registered client a client identifier -- a unique string 
representing the registration information provided by the client. [...] The 
client identifier is unique to the authorization server."

4. (non-normative reference) OpenID Connect Dynamic Client Registration 1.0 
incorporating errata set 2, Section 2: "Clients have metadata associated with 
their unique Client Identifier at the Authorization Server."; Section 3.1: "The 
Authorization Server assigns this Client a unique Client Identifier"; Section 
3.2: "client_id REQUIRED. Unique Client Identifier. It MUST NOT be currently 
valid for any other registered Client. "

Instructions:
-
This erratum is currently posted as "Reported". (If it is spam, it 
will be removed shortly by the RFC Production Center.) Please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
will log in to change the status and edit the report, if necessary.

--
RFC7591 (draft-ietf-oauth-dyn-reg-30)
--
Title   : OAuth 2.0 Dynamic Client Registration Protocol
Publication Date: July 2015
Author(s)   : J. Richer, Ed., M. Jones, J. Bradley, M. Machulak, P. Hunt
Category: PROPOSED STANDARD
Source  : Web Authorization Protocol
Area: Security
Stream  : IETF
Verifying Party : IESG

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

[OAUTH-WG] OAuth 2.0 Protected Resource Metadata draft addressing all known issues

[Michael Jones]

Aaron Parecki and I have published a draft of the 
"OAuth 2.0 Protected Resource Metadata" specification that addresses all the 
issues that we're aware of. In particular, the updates address the comments 
received during the discussions at IETF 118. As described in the History entry 
for -02, the changes were:
*Switched from concatenating .well-known to the end of the resource 
identifier to inserting it between the host and path components of it.
*Have WWW-Authenticate return resource_metadata rather than resource.



The specification is available at:
*
https://www.ietf.org/archive/id/draft-ietf-oauth-resource-metadata-02.html

-- Mike

P.S.  This note was also published at https://self-issued.info/?p=2486 and 
referenced from https://twitter.com/selfissued/status/1750366239493677354.


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

[OAUTH-WG] I-D Action: draft-ietf-oauth-resource-metadata-02.txt

[internet-drafts]

Internet-Draft draft-ietf-oauth-resource-metadata-02.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:draft-ietf-oauth-resource-metadata-02.txt
   Pages:   23
   Dates:   2024-01-24

Abstract:

   This specification defines a metadata format that an OAuth 2.0 client
   or authorization server can use to obtain the information needed to
   interact with an OAuth 2.0 protected resource.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-metadata/

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-resource-metadata-02

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-oauth-resource-metadata-02

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


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

Re: [OAUTH-WG] client_id in CWT Claims

[Orie Steele]

Yes, you are correct.

Based on: https://www.rfc-editor.org/rfc/rfc8392.html#section-9.1.1

It seems like all that is needed to correct this, is to ask the experts to
repeat this process for "client_id".

And no new document would be required.

OS




On Wed, Jan 24, 2024 at 12:44 PM Neil Madden 
wrote:

> RFC8693 didn't register anything for CWT at all. Some other document has
> registered scope for CWT and pointed at that RFC as the reference for some
> reason.
>
> -- Neil
>
> On 24 Jan 2024, at 18:37, Orie Steele  wrote:
>
> I'm working on a document that has some similarity to EAT from RATS, in
> that it is trying to enable JWT and CWT to be used for a use case.
>
> Is there a reason that RFC8693 registers "scope" and "client_id" for JWT,
> but only "scope" for CWT ?
>
> - https://www.iana.org/assignments/jwt/jwt.xhtml
> - https://www.iana.org/assignments/cwt/cwt.xhtml
>
> How can I use "client_id" in CWT ?
>
> OS
>
> --
>
> ORIE STEELE
> Chief Technology Officer
> www.transmute.industries
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>

-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries


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

Re: [OAUTH-WG] client_id in CWT Claims

[Neil Madden]

RFC8693 didn't register anything for CWT at all. Some other document has 
registered scope for CWT and pointed at that RFC as the reference for some 
reason. 

-- Neil

> On 24 Jan 2024, at 18:37, Orie Steele  wrote:
> 
> I'm working on a document that has some similarity to EAT from RATS, in that 
> it is trying to enable JWT and CWT to be used for a use case.
> 
> Is there a reason that RFC8693 registers "scope" and "client_id" for JWT, but 
> only "scope" for CWT ?
> 
> - https://www.iana.org/assignments/jwt/jwt.xhtml 
> 
> - https://www.iana.org/assignments/cwt/cwt.xhtml 
> 
> 
> How can I use "client_id" in CWT ?
> 
> OS
> 
> -- 
> 
> ORIE STEELE
> Chief Technology Officer
> www.transmute.industries
>  
> ___
> 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-WG] client_id in CWT Claims

[Orie Steele]

I'm working on a document that has some similarity to EAT from RATS, in
that it is trying to enable JWT and CWT to be used for a use case.

Is there a reason that RFC8693 registers "scope" and "client_id" for JWT,
but only "scope" for CWT ?

- https://www.iana.org/assignments/jwt/jwt.xhtml
- https://www.iana.org/assignments/cwt/cwt.xhtml

How can I use "client_id" in CWT ?

OS

-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries


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

Re: [OAUTH-WG] IETF119 - Call for topics

[Kristina Yasuda]

Hi,

Editors would like to discuss SD-JWT progress.

I would also like to discuss client attestation draft, it would be good to have 
more time than last time to be able to have substantial discussion because I 
feel like there are few issues that would benefit from that – mainly client 
authentication vs client attestation topic.

Thank you,
Kristina

From: OAuth  On Behalf Of Rifaat Shekh-Yusef
Sent: Wednesday, January 24, 2024 6:15 AM
To: oauth 
Subject: [OAUTH-WG] IETF119 - Call for topics

All,

This is a call for topics for the coming IETF119 in Brisbane.

Please, let us know as soon as possible if you have topics that you would like 
to discuss.
This will help us request enough sessions to address the requested topics.

Note that if we do not get the list before Feb 2nd, we might request less 
sessions than we usually do.
This might impact the time allocated to each topic or might force us to drop 
some topics.

Regards,
 Rifaat & Hannes



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

[OAUTH-WG] IETF119 - Call for topics

[Rifaat Shekh-Yusef]

All,

This is a call for topics for the coming IETF119 in Brisbane.

Please, let us know *as soon as possible *if you have topics that you
would like to discuss.
This will help us request enough sessions to address the requested topics.

*Note that if we do not get the list before Feb 2nd, we might request less
sessions than we usually do.*
*This might impact the time allocated to each topic or might force us to
drop some topics.*

Regards,
 Rifaat & Hannes
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] [OAuth Transaction Tokens] PR #57 Update

[George Fletcher]

Hi,

I've updated PR #57 [1] to address the following issues:

Issue #56 [2] - RFC 9493 and sub_id formats
Issue #58 [3] - Authorization details presentation and processing
Issue #60 [4] - Use of actor_token and actor_token_type
Issue #61 [5] - How is the purp claim of the Txn-Token defined?

[1] https://github.com/oauth-wg/oauth-transaction-tokens/pull/57
[2] https://github.com/oauth-wg/oauth-transaction-tokens/issues/56
[3] https://github.com/oauth-wg/oauth-transaction-tokens/issues/58
[4] https://github.com/oauth-wg/oauth-transaction-tokens/issues/60
[5] https://github.com/oauth-wg/oauth-transaction-tokens/issues/61

Please review. I believe this closes the required updates for this PR.

Thanks,
George

__



The information contained in this e-mail may be confidential and/or proprietary 
to Capital One and/or its affiliates and may only be used solely in performance 
of work or services for Capital One. The information transmitted herewith is 
intended only for use by the individual or entity to which it is addressed. If 
the reader of this message is not the intended recipient, you are hereby 
notified that any review, retransmission, dissemination, distribution, copying 
or other use of, or taking of any action in reliance upon this information is 
strictly prohibited. If you have received this communication in error, please 
contact the sender and delete the material from your computer.



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