see inline On Tue, Nov 14, 2017 at 10:59 AM, 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? > I vote for *c* > > > 2.) Should the work on Client Token (https://tools.ietf.org/html/d > raft-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. > I vote for separate document for Client Token, I like the idea but I think it comes as a natural extension to the framework. > > 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? > Agree > > 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) > I liked Carstens comment "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." So +1 on that. > 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. > > 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/d > raft-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 AS should return one profile, I would like to avoid negotiation, for now at least. > > > Regards, > > Ludwig > > -- > Ludwig Seitz, PhD > Security Lab, RISE SICS > Phone +46(0)70-349 92 51 > > _______________________________________________ > Ace mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ace >
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
