Hi all, On 09/10/2020 02:10 PM, Stefanie Gerdes wrote:
> We also should decouple the AS request creation hints from the > explanation of the AS discovery mechanism. The hints have the additional > purpose that they may contain the resource server's cnonce that the > resource server can later use to validate the access token. > Therefore, the AS URI should be optional in the AS request creation > hints, and we should make section 5.1.1 section 5.2. Looking at section 5.1, I think that we would need to change the text in there, too. old: In order to determine the AS in charge of a resource hosted at the RS, C MAY send an initial Unauthorized Resource Request message to RS. RS then denies the request and sends the address of its AS back to C. Instead of the initial Unauthorized Resource Request message, other discovery methods may be used, or the client may be pre-provisioned with an RS-to-AS mapping. new: C must discover the AS in charge of RS to determine where to request the access token. To do so, C must 1. find out the AS URI to which the token request message must be sent and 2. MUST validate that the AS with this URI is authorized to provide access tokens for this RS. In order to determine the AS URI, C MAY send an initial Unauthorized Resource Request message to RS. RS then denies the request and sends the address of its AS back to C (see section 5.2). How C validates the AS authorization is not in scope for this document. C may, e.g., ask it's owner if this AS is authorized for this RS. C may also use a mechanism that addresses both problems at once. Viele Grüße Steffi _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
