> On Nov 14, 2017, at 17:59, Ludwig Seitz <[email protected]> wrote: > > Hello ACE, > > during the IETF 100 session there were a number of questions on > draft-ietf-ace-oauth-authz that I would like to bring to the list for > feedback: > > 1.) Currently the framework requires the use of CBOR as data object format > and of parameter name abbreviations. Some comments voiced the opinion that > these requirements should be relaxed and the choice left to the profiles. > I see the following options: > > a.) Keep it as it is (i.e. CBOR and parameter name abbreviations REQUIRED) > > b.) Remove all requirements (i.e. data format totally up to the profiles) > > c.) RECOMMEND the use of CBOR and parameter abbreviations (allowing profiles > to specify something else) > > What does the group think we should do?
Clearly (c) (RECOMMEND). If is good to have a common way of doing this, but if a profile has a good reason to deviate, state that reason and deviate. > 2.) Should the work on Client Token > (https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-08#section-5.7.4) be > in the draft or moved out to a separate document? > > Background: We designed Client Token to address the use cases where the > client has intermittent connectivity and needs to receive information from > the AS. No opinion on document splitting. > 4.) What parameters to put into the response to an unauthorized request > (https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-08#section-5.1.2)? > > Jim Schaad suggested to add information about the audience and scope the RS > expects to grant access to the given resource > (https://mailarchive.ietf.org/arch/msg/ace/iObf0ECho--7FCYWBRQYUHtOsBw) > > We have had some discussion on this topic already, but I have not seen a > conclusive "decision" by the group (if such a thing can exist) as to what to > do. It should be up to the deployment what it wants to reveal here. So do provide a way to include this information, but do not require it. > 5.) Francesca suggested to allow the AS to return a list of possible profiles > to the client in response to an access token request. Currently only one > profile is selected and optionally returned by the AS (it could even be > implicit and not be returned at all). > > Background: The way I was thinking this should work was that both the client > and the RS need to be registered at the AS in order for the exchanges to > work. I made the assumption > (https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-08#appendix-D) that > the AS would already know which profiles both C and RS support, and thus just > select the ideal one. > > What does the group think, should we instead allow for a list of profiles and > let the client select which one to use? I’m not quite convinced about the use case, but I also don’t see much harm (this is a less-constrained, horizontal protocol). SAM (AS) won’t necessarily be “closely familiar” with C, so C (or the CAM component of it) may be able to make a better choice. Grüße, Carsten _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
