Camara OIDC profile #121
Camara OIDC profile #121
Conversation
Signed-off-by: Axel Nennker <axel.nennker@telekom.de>
Signed-off-by: Axel Nennker <axel.nennker@telekom.de>
Addind section on sender-constraint access tokens and DPoP
Added a line about PCR and another one for scopes
Add section about OIDF certification
Shilpa padgaonkar patch 1
Specify error handling if openid is missing in scope
handling of acr_values
…tokens Removed the recommendation for sender-constraint access tokens and the recommendation for using DPoP
restructure section on purpse fixed typo
|
What is the intention for parameters and behaviour that remain optional (whether recommended or only optional)? Is it the intention that an API provider can choose which optional features to support and which not? |
Add example to purpose in scope section. Repeating purpose for each technical scope to avoid proprietary implementation of AZ which would lead to vendor lock-in Avoid special semantics
fixed < and > being interpreted as html
Amended "Purpose as part of scope"
fix markdown
|
@eric-murray @sfnuser @palmerabollo @izahirclemencia @Elisabeth-Ericsson @bigludo7 @sebdewet Sorry for spamming, but as the GitHub messages about my "requested review" and "removed request" are looking strange I want shortly confirm that your final reviews are requested now, after we agreed in smaller round today on the "Option 1" as the solution for the purpose topic. |
Co-authored-by: Elisabeth-Ericsson <121795930+Elisabeth-Ericsson@users.noreply.github.com>
Co-authored-by: Herbert Damker <52109189+hdamker@users.noreply.github.com>
Co-authored-by: Herbert Damker <52109189+hdamker@users.noreply.github.com>
|
Please review (and approve) |
jpengar
added
the
v0.2-candidate
hdamker
left a comment
hdamker
left a comment
There was a problem hiding this comment.
LGTM - thanks for all the discussions and resolutions!
sfnuser
left a comment
sfnuser
left a comment
There was a problem hiding this comment.
Thanks for driving this effort and getting a closure.
I made one suggestion. Feel free to push it later if an editorial PR is planned.
|
|
||
| ### Outlook on purpose-handling leveraging Rich Authorization Request | ||
|
|
||
| [RFC 9396 OAuth 2.0 Rich Authorization Requests](https://www.rfc-editor.org/rfc/rfc9396) defines a OAuth2 parameter `authorization_details` that is used to carry fine-grained authorization data. The parameter `authorization_details` can be used in all places where OAuth2 allows the `scope` parameter. That means that the parameter `authorization_details` can be used in all places where OIDC and CIBA allow the `scope` parameter. |
There was a problem hiding this comment.
| [RFC 9396 OAuth 2.0 Rich Authorization Requests](https://www.rfc-editor.org/rfc/rfc9396) defines a OAuth2 parameter `authorization_details` that is used to carry fine-grained authorization data. The parameter `authorization_details` can be used in all places where OAuth2 allows the `scope` parameter. That means that the parameter `authorization_details` can be used in all places where OIDC and CIBA allow the `scope` parameter. | |
| [RFC 9396 OAuth 2.0 Rich Authorization Requests](https://www.rfc-editor.org/rfc/rfc9396) defines a OAuth2 parameter `authorization_details` that is used to carry fine-grained authorization data. The parameter `authorization_details` can be used in all places where OAuth2 allows the `scope` parameter. That means that the parameter `authorization_details` can be used in all places where OIDC or OAuth2 allow the `scope` parameter. |
There was a problem hiding this comment.
RAR says that authorization_details can be used in all places scope can be used. RAR does not mention CIBA.
But, yes, we can mention CIBA here.
There was a problem hiding this comment.
@AxelNennker the suggestion is to replace "OIDC and CIBA" by "OIDC or OAuth2", so NOT to mention CIBA. The suggestion makes sense for me, but I propose to do it in a later editorial PR. No need to dismiss the already done approvals for that.
jpengar
left a comment
jpengar
left a comment
There was a problem hiding this comment.
LGTM - thank you all for your valuable contributions.
| If "openid" is missing in the scope value but a claim that is [standardized in OIDC](https://openid.net/specs/openid-connect-core-1_0.html#Claims) is requested, then the Authorization Server returns an HTTP response code of 400 (Bad Request) and an error invalid_request. | ||
|
|
||
| Clients SHOULD follow the OIDC standard and SHOULD include `openid` in the list of requested scopes. | ||
| Without id token there is no `sub` field and the privacy features of OIDC are severely crippled. |
There was a problem hiding this comment.
| Without id token there is no `sub` field and the privacy features of OIDC are severely crippled. | |
| Without id token there is no mandatory `sub` field and the privacy features of OIDC are severely crippled. |
Please note that the sub field is also there in the access token, but not optional.
From RFC 7519: The "sub" (subject) claim identifies the principal that is the
subject of the JWT. The claims in a JWT are normally statements
about the subject. The subject value MUST either be scoped to be
locally unique in the context of the issuer or be globally unique.
The processing of this claim is generally application specific. The
"sub" value is a case-sensitive string containing a StringOrURI
value. Use of this claim is OPTIONAL.
17 participants
What type of PR is this?
Add one of the following kinds:
What this PR does / why we need it:
By restricting options the OIDF and IETF standards offer this document improves CAMARA security and interoperability.
The CAMARA Security and Interoperability document follows the path FAPI 2.0 Security took, leading to a concise description which helps implementers focusing on those parts of the standards that are required or recommended.
Which issue(s) this PR fixes:
Fixes #78
Fixes #82
Fixes #87
Fixes #90
Fixes #100
Fixes #104
Fixes #127
Fixes #132
Fixes #133
Fixes #136
Fixes #137