[OAUTH-WG] Weekly github digest (OAuth Activity Summary)

[Repository Activity Summary Bot]

Events without label "editorial"

Issues
--
* oauth-wg/oauth-sd-jwt-vc (+0/-1/💬2)
 1 issues received 2 new comments:
 - #145 how cnf claim can be used with any other types of "binding" (2 by 
danielfett, peppelinux)
   https://github.com/oauth-wg/oauth-sd-jwt-vc/issues/145 [discuss] 


 1 issues closed:
 - Define the concept of a credential type https://github.com/oauth-wg/oauth-sd-jwt-vc/issues/181 [HAS PR] [wg-04] 


* oauth-wg/oauth-selective-disclosure-jwt (+0/-0/💬2)
 1 issues received 2 new comments:
 - #416 Add Test suite for SD-JWT (2 by bc-pi, lukasjhan)
   https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/416 [ready-for-PR] 


* oauth-wg/oauth-v2-1 (+1/-0/💬0)
 1 issues created:
 - Including WebAssembly? (by MozharAlhosni)
   https://github.com/oauth-wg/oauth-v2-1/issues/174 




Pull requests
-
* oauth-wg/oauth-browser-based-apps (+1/-0/💬0)
 1 pull requests submitted:
 - feat: narrowing ascii-art and adding svg support (by duncanwd)
   https://github.com/oauth-wg/oauth-browser-based-apps/pull/50 


* oauth-wg/oauth-transaction-tokens (+0/-0/💬1)
 1 pull requests received 1 new comments:
 - #90 specified language for self-signed JWTs as subject_tokens (1 by tulshi)
   https://github.com/oauth-wg/oauth-transaction-tokens/pull/90 


* oauth-wg/oauth-sd-jwt-vc (+0/-1/💬1)
 1 pull requests received 1 new comments:
 - #220 feat: add SD-JWT VC Type Metadata (1 by awoie)
   https://github.com/oauth-wg/oauth-sd-jwt-vc/pull/220 


 1 pull requests merged:
 - feat: add SD-JWT VC Type Metadata
   https://github.com/oauth-wg/oauth-sd-jwt-vc/pull/220 


* oauth-wg/oauth-selective-disclosure-jwt (+1/-0/💬1)
 1 pull requests submitted:
 - Update Rust option in the Implementations list (by jovfer)
   https://github.com/oauth-wg/oauth-selective-disclosure-jwt/pull/422 


 1 pull requests received 1 new comments:
 - #394 Distinguish SD-JWT from SD-JWT+KB (1 by danielfett)
   https://github.com/oauth-wg/oauth-selective-disclosure-jwt/pull/394 


* oauth-wg/oauth-v2-1 (+1/-0/💬2)
 1 pull requests submitted:
 - Remove duplicate "are" (by MozharAlhosni)
   https://github.com/oauth-wg/oauth-v2-1/pull/175 


 1 pull requests received 2 new comments:
 - #172 clarify expires_in is a JSON number (2 by MozharAlhosni, panva)
   https://github.com/oauth-wg/oauth-v2-1/pull/172 



Repositories tracked by this digest:
---
* https://github.com/oauth-wg/oauth-browser-based-apps
* https://github.com/oauth-wg/oauth-identity-chaining
* https://github.com/oauth-wg/oauth-transaction-tokens
* https://github.com/oauth-wg/oauth-sd-jwt-vc
* https://github.com/oauth-wg/draft-ietf-oauth-resource-metadata
* https://github.com/oauth-wg/oauth-cross-device-security
* https://github.com/oauth-wg/oauth-selective-disclosure-jwt
* https://github.com/oauth-wg/oauth-v2-1
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Genart last call review of draft-ietf-oauth-security-topics-25

[Daniel Fett]

Thank you Thomas for your feedback!

I merged your PR and will release a new version soon.

-Daniel

Am 18.02.24 um 15:52 schrieb Thomas Fossati via Datatracker:

Reviewer: Thomas Fossati
Review result: Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-oauth-security-topics-25
Reviewer: Thomas Fossati
Review Date: 2024-02-18
IETF LC End Date: 2024-02-22
IESG Telechat date: Not scheduled for a telechat

Summary:

This document contains the BCP for OAuth 2.0

It is well written, with a clear structure, and it contains a wealth of useful 
information.

Thank you, editors and the OAUTH WG for an excellent document.

Major issues:

None

Minor issues:

None

Nits/editorial comments:

I have filed a PR to fix a few typos.

[1]https://github.com/oauthstuff/draft-ietf-oauth-security-topics/pull/90

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

[OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-26.txt

[internet-drafts]

Internet-Draft draft-ietf-oauth-security-topics-26.txt is now available. It is
a work item of the Web Authorization Protocol (OAUTH) WG of the IETF.

   Title:   OAuth 2.0 Security Best Current Practice
   Authors: Torsten Lodderstedt
John Bradley
Andrey Labunets
Daniel Fett
   Name:draft-ietf-oauth-security-topics-26.txt
   Pages:   60
   Dates:   2024-04-21

Abstract:

   This document describes best current security practice for OAuth 2.0.
   It updates and extends the threat model and security advice given in
   RFC 6749, RFC 6750, and RFC 6819 to incorporate practical experiences
   gathered since OAuth 2.0 was published and covers new threats
   relevant due to the broader application of OAuth 2.0.  It further
   deprecates some modes of operation that are deemed less secure or
   even insecure.

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

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-oauth-security-topics-26.html

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

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] Artart last call review of draft-ietf-oauth-security-topics-25

[Daniel Fett]

Hi Russ,

thank you for your feedback on the OAuth Security BCP draft! I 
incorporated most of the proposed changes into the latest version (-26).


Some comments below:

Am 18.02.24 um 22:27 schrieb Russ Housley via Datatracker:

Reviewer: Russ Housley
Review result: Almost Ready

I am the assigned ART-ART reviewer for this draft. Please treat these
comments just like any other last call comments.


Document: draft-ietf-oauth-security-topics-25
Reviewer: Russ Housley
Review Date: 2024-02-18
IETF LC End Date: 2024-02-22
IESG Telechat date: Unknown


Summary: Almost Ready

Major Concerns:

Section 4: Some of the subsections contain MUST, MUST NOT, SHOULD, and
MAY statements.  Given the structure of the document, I expected all of
the words that are defined in RFC 2119 to appear is Section 2, with
discussion of attacks in Section 4.  Please consider lower case words.


I absolutely see where you are coming from, but Section 4 intentionally 
provides normative requirements on top of those in Section 2. Our 
intention is to provide a brief rundown of the most important Best 
Practices in Section 2. However, some requirements are only applicable 
in certain cases (e.g., protocol options not commonly used), some 
require a lengthy detailed explanation, and some require explaining the 
context of a certain attack in order to make sense. Those are listed in 
Section 4.


Removing all requirements from Section 4 would effectively mean merging 
Sections 2 and 4. Since Section 2 was introduced in reponse to demands 
for a summary of the most important measures, we would prefer not to do 
that.


We did check carefully that the requirements defined in Section 4 
complement, but never contradict, those in Section 2.


I noticed, however, that the introductions to Sections 2 and 4 did not 
provide the full picture - I therefore changed the introduction to 
Section 2 to the following:


   This section describes the core set of security mechanisms and
   measures the
   OAuth working group considers best practices at the time of writing.
   Details
   about these security mechanisms and measures (including detailed attack
   descriptions) and requirements for less commonly used options are
   provided in
   (#attacks_and_mitigations).

And the one of Section 4 to the following:

   This section gives a detailed description of attacks on OAuth
   implementations,
   along with potential countermeasures. Attacks and mitigations
   already covered in
   [@!RFC6819] are not listed here, except where new recommendations
   are made.

   This section further defines additional requirements beyond those
   defined in
   Section (#recommendations) for certain cases and protocol options.



Minor Concerns:

Section 1: I recognize that the term "Anti-patterns" is gaining favor,
but I still think that you should provide a brif introduction to the
concept.  Perhaps: Anti-patterns are patterns in software development
that are considered bad programming practices, but they seem to happen
over and over.

Done!


Section 2.3: It says:

...  If not, the resource server must refuse to
serve the respective request. ...

The "If not" is ambiguous.  Which aspects of the previous sentence
does this cover?  Part is implemented by the access server and part is
implemented by the resource server.  Can the resource server always
determin whether the "the authorization server associates the access
token with the respective resource and actions"?  Please clarify.
Good catch, thank you! I expanded the "If not" to "If it was not", 
making clear that it refers to this part of the previous sentence: "... 
whether (...) was meant to be used for that particular resource server."


Section 2.5: When is client authentication not possible?  In other
words, under what circumstances does an authorization server
implementer ignore this SHOULD statement?


Thanks, changed to:

   Authorization servers SHOULD enforce client authentication if
   it is feasible, in the particular deployment, to establish a process for
   issuance/registration of credentials for clients and ensuring the
   confidentiality of those credentials.




Section 4.1.1: The text says: "First, the attacker ..."  However, there
is not "Second" or "Then" to go wit the "First".  Please reword.
Perhaps: s/First/To begin/


Changed as proposed.




Section 4.1.2: The text says: "First, the attacker ..."  However, there
is not "Second" or "Then" to go wit the "First".  Please reword.
Perhaps: s/First/To begin/


Changed as proposed.





Nits:

Abstract: Because the Abstract is not allowed to contain references:
   s/[RFC6749], [RFC6750], and [RFC6819]/
/RFC 6749, RFC 6750, and RFC 6819/

fixed

Section 1: s/client talks to/client is talking to/

fixed


Section 1: s/when feasible/as soon as feasible/

fixed


Section 2.5: s/authentication if possible./authentication./

Changed as shown above


Section 3: s/attacker model/threat model/ (multiple places)

[OAUTH-WG] I-D Action: draft-ietf-oauth-attestation-based-client-auth-02.txt

[internet-drafts]

Internet-Draft draft-ietf-oauth-attestation-based-client-auth-02.txt is now
available. It is a work item of the Web Authorization Protocol (OAUTH) WG of
the IETF.

   Title:   OAuth 2.0 Attestation-Based Client Authentication
   Authors: Tobias Looker
Paul Bastian
   Name:draft-ietf-oauth-attestation-based-client-auth-02.txt
   Pages:   14
   Dates:   2024-04-21

Abstract:

   This specification defines a new method of client authentication for
   OAuth 2.0 [RFC6749] by extending the approach defined in [RFC7521].
   This new method enables client deployments that are traditionally
   viewed as public clients to be able to authenticate with the
   authorization server through an attestation based authentication
   scheme.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-attestation-based-client-auth/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-oauth-attestation-based-client-auth-02.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-oauth-attestation-based-client-auth-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