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

[Samuel Erdtman <[e-mail]>]

see inline

On Thu, Jun 21, 2018 at 5:58 PM, Jim Schaad <[e-mail]> wrote:

> I sent this review early by accident (I thought I was sending a different
> mail).
>
>
>
> However a couple things below.
>
>
>
>
>
> *From:* Samuel Erdtman <[e-mail]>
> *Sent:* Thursday, June 21, 2018 8:15 AM
> *To:* Jim Schaad <[e-mail]>
> *Cc:* [e-mail]; ace <[e-mail]>
> *Subject:* Re: [Ace] Review of draft-ietf-ace-oauth-authz -12
>
>
>
> 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.
>
>
>
> [JLS] Yeah I agree that ‘client information’ is not really any better.  I
> wonder if ‘Access Information’ might be a better term?
>

I have create an issue so that it is not forgotten at least.


>
>
>
>
>
> 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.
>
>
>
> [JLS] This is not clear to me from what is stated.  Does this mean that
> there is going to be AS pointers that are contained on the RD entry for the
> resource that one is interested in?  If that is the case then a pointer to
> where those fields are (going) to be defined would be useful.  I read this
> as searching the RD for an AS directly.
>

I did some more reading and I agree the text implies that there is a AS
pointer in the RD. I could not find such registration in this document.
I have created a github issue to either add this information or remove the
text that implies so.


>
>
>
> 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.
>
>
>
> [JLS] I am implementing all of my credentials as being something that is
> either a) cooked in to the device or b) as a COSE Key which is part of a
> database which is read up by the program.  As such I do not believe I am
> using anything from this draft.  Part of what I am trying to figure out
> here is what the status of this document is and what dependencies the Authz
> document has one it.  Is it really informational?  What does it do for the
> Authz document to have it referenced?  Should this document be pushed up to
> a WG document because it is really needed?   My understanding from RFC6749
> is that these are client credentials that are being used in the HTTP
> authentication rather then the TLS client auth layer below HTTP.   On the
> other hand this is not completely clear.
>

The draft (erdtman-ace-rpcc) is not concerned about how the key is stored.
Id describes how to use the key as a client credential with (D)TLS
Raw-Public-Key or Pre-Shared-Key. (depending on the key type).
The reference is informational as far as I can tell, it is used to
exemplify how the OAuth client authentication can be extended.
RFC6749 (The OAuth 2.0 Authorization Framework) describes one type of
client credentials and that is (client_id/username and
client_secret/password). In my opinion that is not a great fit for the IoT
use case with limited user interactions and interfaces. Therefore I created
the draft (erdtman-ace-rpcc) to describe how to use Raw-Public-Key or
Pre-Shared-Key to authenticate the client, i.e. I think there is value in
the document.
With that said there is no absolute need for it from
draft-ietf-ace-oauth-authz point of view.


>
>
>
>
> [JLS] These are not finished questions – not surprised you did not respond.
>
> :-)

>
>
> Jim
>
>
>
> 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
>
>
>