Ludwig Seitz <[email protected]> writes: > 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?
I am in favor for (a) but (c) would be the more flexible choice for a future-proof framework. > 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 here. > 3.) What is the relationship to the Token Binding Work at OAuth > (https://datatracker.ietf.org/doc/draft-ietf-oauth-token-binding/) ? > > 3-bis.) To me it seems like this could go into a profile of the ACE > framework. Would someone be willing to write such a draft? > > > 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. I suggest to add this information (as optional fields) to the response so the client knows what to request from AS. > 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 think that negotiating the profile between C and AS is inevitable but returning a list of profiles with the AS-to-Client response might be difficult because there might be profile-specific claims that need to be included as well. I prefer a client-driven negotiation mechanism where the client may send the list of profiles it supports, and the server picks one of this list or returns an error if the resource server does not support any of these. If the client does not send this list, AS just picks one as described by Ludwig. Grüße Olaf _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
