> -----Original Message-----
> From: Ludwig Seitz <[email protected]>
> Sent: Thursday, January 31, 2019 1:20 AM
> To: Jim Schaad <[email protected]>; draft-ietf-ace-oauth-
> [email protected]
> Cc: [email protected]
> Subject: Re: Shepard review for draft-ietf-ace-oauth-authz
>
> On 30/01/2019 19:23, Jim Schaad wrote:
> >
> >
> >> -----Original Message----- From: Ludwig Seitz <[email protected]>
> >> Sent: Wednesday, January 30, 2019 12:38 AM To: Jim Schaad
> >> <[email protected]>; draft-ietf-ace-oauth- [email protected] Cc:
> >> [email protected] Subject: Re: Shepard review for
> >> draft-ietf-ace-oauth-authz
> >>
> >> Thank you Jim,
> >>
> >> I'll upload a new version as soon as we have resolved my questions
> >> below.
> >>
> >> /Ludwig
> >>
> >> On 30/01/2019 07:01, Jim Schaad wrote:
> >>> 1. Update the reference from RFC 5246 to RFC 8446 in all locations
> >>>
> >>>
> >>>
> >>> Items that don't appear to be resolved:
> >>>
> >>> * Section 3.1 - Refresh Token - I don't think that refresh tokens
> >>> are going to be strings because binary is more efficient. Unless you
> >>> are going to say that this is not OAuth 2.0, then a refresh token is
> >>> still a text string.
> >>>
> >>> * I don't see any text that is addressing this.
> >>
> >> That text just describes how it is in OAuth 2.0 (where refresh tokens
> >> are strings), since we didn't see the need to specify the use of
> >> refresh tokens in ACE, we didn't mention them further. If we had we
> >> would certainly have defined them to be binary.
> >
> > That would be fine, but you actually do define a CBOR mapping tag for
> > refresh tokens in the body of the text and define it as binary.
> >
> Right,
> (background: I did define a mapping for all OAuth parameters and re-
> mapped all that were Strings to binary. That does not necessarily mean the
> have a use case currently in ACE.)
>
> in order to resolve this I will add a sentence in the description of the
> refresh
> token, saying that we define them to be binary here.
>
>
> >>> ****** IANA Section Issues
> >>>
> >>> 1. None of the new registries appear to have any guidance for
> >>> the DEs to use when approving items.
> >>
> >> Is it acceptable to add a single guidance section for all of the
> >> new registries, or does it need to be separate for each of them?
> >
> > As long as the guidance is comment this is fine. That is what I did
> > for all of the COSE registries
> >
>
> I'll copy liberally from your example then (and a bit from the CWT RFC).
> Hope you don't mind.
I never really object to copying things that work. Just think for a bit f
anything is missing. I will probably be doing some expanding of them in the
move forward to Full Standard.
>
>
> >>>
> >>> 2. The title of the registry "ACE Authorization Server
> >>> Information" is not really descriptive of what is in the
> >>> registry. It makes sense in the text but not as a stand along
> >>> title. Something along the lines of "ACE Authorization Server
> >>> Request Creation Hints" seems to be closer to a solid
> >>> identification.
> >>>
> >> Would "ACE Authorization Server Discovery Hints" be better?
> >
> > I thought about that, but it does not really cover the idea of having
> > the nonce value there or the possibility of later adding things like
> > - ok you should use this audience or this scope or some other similar
> > thing.
> >
>
> I see. I'll use the somewhat clunky but descriptive "ACE Authorization
> Server Request Creation Hints".
>
> I've also taken the liberty of adding audience (req_aud) and scope as
> optional parameters in the AS Request Creation Hints message, in order
> to justify its name.
I have always thought that those two items should be there anyway.
Jim
>
>
>
> While resolving issues from the DTLS profile the authors have noticed
> two elements that need to be added to the framework:
>
> 1.) A definition of "Authorization Information"
> "The information an RS uses to determine wether a request is authorized,
> including the claims of applicable access tokens."
>
> 2.) Adding the "kid" parameter to the AS Request Creation Hints, so that
> a client can request a token with the same pop key when it has an
> existing security association, but the token has expired.
> The procedure is currently defined in the DTLS profile, but it applies
> to any other profile as well and should therefore be in the framework.
>
>
> /Ludwig
>
> --
> Ludwig Seitz, PhD
> Security Lab, RISE
> Phone +46(0)70-349 92 51
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
