Skip to content

Issue #350 - dropping algo strictness #356

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
appsdesh wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Issue #350 - dropping algo strictness #356

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
27 changes: 22 additions & 5 deletions openid-caep-interoperability-profile-1_0.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -86,6 +86,7 @@ normative:
RFC6750: # The OAuth 2.0 Authorization Framework: Bearer Token Usage
RFC8414: # OAuth 2.0 Authorization Server Metadata
RFC6749:
RFC8725: # JSON Web Token Best Current Practices
FAPI:
target: https://openid.net/specs/fapi-security-profile-2_0-final.html
title: FAPI 2.0 Security Profile
Expand Down Expand Up @@ -344,10 +345,18 @@ Receivers MUST be prepared to accept events with any of the subject identifier
formats specified in this section. Transmitters MUST be able to send events with
at least one of the subject identifier formats specified in this section.

## Event Signatures
## Event Signatures {#event-signatures}

All events MUST be signed using the `RS256` algorithm with a minimum of
2048-bit keys.
All events MUST be signed using JWS as described in {{RFC8417}} Section 5.1.
This profile does not permit unsecured SETs, even when integrity is provided
by other means such as TLS; the `none` algorithm MUST NOT be used or accepted.

The Transmitter and Receiver MUST use a mutually supported signing algorithm,
established by means outside the scope of this profile. Receivers MUST reject

@thomasdarimont thomasdarimont Sep 29, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would that wording still allow SSF signature negotiation mechanisms as suggested by Joseph? #355

@appsdesh appsdesh Sep 29, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Signature negotiation is general aspect of JWKS based validations, imo, we should not take dependency on it and add any specific language around it

events signed with an algorithm they are not configured to accept.
Comment on lines +355 to +356

@jogu jogu Sep 29, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This feel like it should be a part of the base spec, not the interop profile.

@appsdesh appsdesh Sep 29, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

base spec calls SET signatures as optional, we are making it mandatory in interop spec, hence added here


RSA keys MUST have a minimum length of 2048 bits when using an RSA-based
algorithm.

## OAuth Support

Expand Down Expand Up @@ -488,10 +497,17 @@ Transmitter, per {{CAEP}} 1.0 §3.8.1.

# Security Considerations

There are no additional security considerations that arise from this document.
Security considerations applicable to this profile are covered in the
"Security Considerations" sections of {{SSF}} and {{CAEP}}.

This profile does not mandate a SET signing algorithm (see
{{event-signatures}}). This allows deployments to adopt stronger algorithms
and retire weaker ones. Receivers remain responsible for enforcing their own
Comment on lines +504 to +505

@jogu jogu Sep 29, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This allows deployments to adopt stronger algorithms and retire weaker ones.

I think that's an over claim. It doesn't provide any mechanism at all for retiring apart from out-of-band negotiation, which is how you do it without the profile. Nor does it have any mechanism for showing a stronger algorithm is available.

@appsdesh appsdesh Sep 29, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you suggesting dropping this sentennce? I wanted to provide forward compatibility when I added it

algorithm policy.
Implementers SHOULD follow {{RFC8725}} when selecting and validating signing
algorithms, and MAY consult the cryptographic requirements in {{FAPI}}
Section 5.4.1.

--- back

# Acknowledgements
Expand Down Expand Up @@ -566,4 +582,5 @@ specification.
* Cleaned up markdown (#91)

-02
* Add Risk Level Change change use-case (#347)
* Add Risk Level Change change use-case (#347)
* Removed RS256 mandate for event signatures (#350)
Loading