> -----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.
>
> >
> >> On 22/10/2018 21:09, Jim Schaad wrote:
> >>> * Section 5.8.2 - If the RS is going to do introspection, can it send
> > some
> >>> type of "Server Busy - try again in xxx" while it does the introspection
> >>> rather than just doing an ack of the request and possibly waiting a long
> >>> time?
> >>
> >> This is probably transport protocol specific, and we were asked not to
> >> link the framework to a specific protocol, thus I don't know if we can
> >> provide guidance here.
> >
> > I think it would be okay to say something like "some transport protocols
> > may provide a way to indicate that the server is busy and the client should
> > retry after an interval; this type of status update would be appropriate
> > while the server is waiting for an introspection response". Which does
> > provide guidance, but in a non-normative fashion that does not require or
> > prohibit any given transport protocol.
> >
> > * I don't see anything that I think addresses this issue. I would expect
> > it to be a security consideration
>
> There is text in the draft according to the suggestion above in section
> 5.8.1 "The Authorization Information Endpoint". Should that text be
> moved to security considerations?
No, I just missed the text. It just took me three times reading through to
find it.
>
> >
> > Comments on protection of CWT/Token: I am wondering if there needs to
> be
> > any comments on how a CWT is going to be protected. While it is ok to use
> > either a symmetric key or a direct key agreement operation for a single
> > recipient without forcing a signature operation to occur. If the token is
> > going to be targeted a single audience hosted on multiple RSs then a
> > signature operation would be required for the purposes of authentication.
> >
>
> Right. I'll add some security considerations on that.
>
>
> > ****** 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
>
> >
> > 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.
>
> > 3. The mapping registries should use the OAuth registry name as a prefix.
> > Thus "OAuth Access Token Types" and "OAuth Access Token Type CBOR
> Mappings".
> >
> Done. Actually quite some changes were required to align all of the
> mappings sections with the OAuth registry names.
>
> > 4. What is the initial registrations that need to occur for the "ACE
> > Profile" registry. If there are none then this needs to be stated.
> >
> It's initially empty, since draft-ieft-ace-oauth-authz doesn't define a
> profile. However the DTLS and OSCORE profile will provide the two
> initial entries. I added a sentence to that effect in the IANA section.
Yea, I thought that was the case since the registrations are actually done in
the profile documents. I just wanted to make sure that IANA realized that this
was initially going to be an empty registry.
Jim
>
> > 5. For the CBOR Web Token Claims - how many of these should have the
> JWT
> > Claim name filled in? It would seem that all of them should. If not a
> > comment about this is needed.
> Fixed.
>
> /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
