Create proposed_stable_requirements.md #114
Conversation
|
|
||
| * _MUST distribute discovery metadata (such as the authorization endpoint) via the metadata document as specified in [OpenID.Discovery];_ | ||
| * _MUST reject requests using the resource owner password credentials grant;_ | ||
| * _MUST support public clients as defined in [RFC6749];_ |
There was a problem hiding this comment.
If for security reasons, an enterprise doesn't want to support public clients, then they can't claim IPSIE one compliance? Or does the IDP enable support for conformance testing and then turn off the support? Is that acceptable?
There was a problem hiding this comment.
I think this is where we landed when we last discussed it. We'll have to go check meeting notes to see.
If we think it's not stable, we can remove it from the proposed list of stable requirements.
There was a problem hiding this comment.
Or maybe require public clients to use DCR? Is that both supporting them and "not" supporting them?
|
|
||
| Access Tokens issued by OpenID Providers: | ||
|
|
||
| * _MUST only be used by the RP to retrieve identity claims at the OpenID Provider;_ |
There was a problem hiding this comment.
I think this is confusing. From an IPSIE perspective, the spec is only addressing the use of access tokens at the /userinfo endpoint to retrieve identity claims. I don't think IPSIE should be limiting how a returned access token may be used by the client. Maybe something like...
- MUST support use by the RP to retrieve identity claims at the OpenID Provider;
There was a problem hiding this comment.
Please leave a PR on the current working draft or file an issue. This was pulled straight from the most recent update.
| * _MUST issue authorization codes with a maximum lifetime of 60 seconds;_ | ||
| * _MUST return an `iss` parameter in the authorization response according to [RFC9207];_ | ||
| * _MUST NOT transmit authorization responses over unencrypted network connections, and, to this end, MUST NOT allow redirect URIs that use the `http` scheme;_ | ||
| * _MUST reject an authorization code (Section 1.3.1 of [RFC6749]) if it has been previously used;_ |
There was a problem hiding this comment.
I'm ok with this requirement though for geo-graphically distributed deployments, this can get complicated for the OPs.
There was a problem hiding this comment.
If you have a suggested fix, file a PR for discussion please.
There was a problem hiding this comment.
We did have issues with this particularly in FAPI1. FAPI itself says no reuse, the position we ended up in the certification tests for final is that exchanging an authorization code 1 second after the first use must be rejected.
gffletch
left a comment
gffletch
left a comment
There was a problem hiding this comment.
Thanks for the responses Dean. I've create two issues. Approving this PR.
3 participants
As an artifact to inspire discussion, I took a set of requirements from the SL1 OIDC profile and highlighted what I believe to be stable requirements (e.g. not likely to change before we get to a final document). The goal is to enable OIDF to start to develop conformance tests as early as possible in the IPSIE lifecycle, while avoiding any tests that are likely to change before IPSIE OIDC SL1 is published.