Re: [Ace] Review of draft-ietf-ace-oauth-authz -12

[Samuel Erdtman <[e-mail]>]

Thanks for reviewing, some answers inline

On Tue, Jun 19, 2018 at 8:05 PM, Jim Schaad <[e-mail]> wrote:

> Based on where I currently am, here is another review of the document.
>
> 1.  In section 4 for Figure one:  Is the term "RS Information" your term or
> an OAuth term.  When I see this I think of it as information for not about
> the RS which I do not believe is the intent.
>

No, the intent is information about the RS for the client. It is described
in "2. Terminology".
Not sure if "client information" would be preferable.


>
> 2.  In section 5.1 - I am unclear what the second paragraph is supposed to
> be doing here.  I think that you want state this different.  Rather than
> talking about the "desired resource" you may want to talk about the AS.
> That would better match the title of the section.
>

The focus could maybe be different but the text is about how to find the AS
but the method for that is quite RS focused.


>
> 3.  In section 5.1 - There is a note in this section that does not seem to
> be extremely useful.  Where is this discussion go on?  Is it still going
> on?
> I am not even sure if the statement about a common understanding of time is
> correct?  It seems that one can either add or not add the nonce as an RS
> depending on if you think you understand a common time.
>

I have not heard anything on the time discussion for a while.


>
> 4.  In section 5.3 - There is a reference to I-D.erdtman-ace-rpcc.  Given
> the use of POP tokens, what is the reason for this draft and the text about
> client credential types?  (Put it this way.  I did not need to implement
> this for anything yet.  Why is it here?)
>

Not sure what profile you have implemented.
I-D.erdtman-ace-rpcc defines how the client can use Raw Public Key or Pre
Shared Key with (D)TLS to authenticate it self to the AS. It is not a
strange operation so you might have implemented it without thinking about
it (Ludwig kind of did). I-D.erdtman-ace-rpcc is similar to
draft-ietf-oauth-mtls that defines what was already done in the wild when
it comes to x509 certificates and client authentication.
Or you might have used default client credentials (client_id/username and
client_secret/password).

I think writing about client credentials is needed since the ACE use cases
so far has been client centric, i.e. the client is often described to
authenticate as it self to get a token and not as is common i OAuth the
user is authenticated and authorizes the client to get a token.
With that said the reference to I-D.erdtman-ace-rpcc should maybe be
removed since interest in I-D.erdtman-ace-rpcc has been very limited.


>
>
>
>
> Given 15 different introspection tokens, how do I decide which is the one
> to
> present to the AS - enumerate them?
>
> 'authorization code' vs 'decode code' grants
>
>
> _______________________________________________
> Ace mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ace
>