[Openid-specs-risc] OAuth 2.0 related text suggestions
dick at amazon.com
Tue Feb 27 02:55:55 UTC 2018
Marius: I previously had asked that we use OAuth 2.0 as an assumption rather than OIDC. Phil’s comments highlighted issues with a deep assumption of OAuth 2.0, such as running an authorization server, that I am agreement with. I do think we want to specify how control plane APIs are authenticated. I do not think we want to specify how an access token is obtained.
Below I have suggested text for the sections that reference client id and OAuth specific language. I think we get interop at transport level by specifying RFC 6750. Allowing other mechanisms for token exchange besides the Client Credential Grant provides flexibility in how various receivers can obtain an access token. For example, it allows a 3 legged flow where the admin clicks through to enable a service provider to act on their behalf. It also allows a manual configuration where the access token is copy and pasted from a website into a service configuration.
Phil: do these changes address your concerns around OAuth 2.0?
HTTP API calls from a receiver to a transmitter SHOULD be authorized
by providing an access token in the WWW-Authenticate HTTP header value per RFC 6750.
The receiver may obtain an access token using the Client Credential Grant [RFC 6749 https://tools.ietf.org/html/rfc6749#section-4.4], or any other method suitable for the receiver and the transmitter.
This section is a profile of the following IETF SecEvent specifications:
Security Event Token (SET) https://datatracker.ietf.org/doc/draft-ietf-secevent-token/
SET Token Delivery Using HTTP https://datatracker.ietf.org/doc/draft-ietf-secevent-delivery/
5.1.5. The "aud" Claim
The 'aud' claim MUST be a single value. It MAY be the client id if the receiver is an OAuth 2.0 client, or any other value that uniquely identifies the receiver to the transmitter.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-risc