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?
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.
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.
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?
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
