I sent this review early by accident (I thought I was sending a different mail).
However a couple things below. From: Samuel Erdtman <sam...@erdtman.se> Sent: Thursday, June 21, 2018 8:15 AM To: Jim Schaad <i...@augustcellars.com> Cc: draft-ietf-ace-oauth-au...@ietf.org; ace <ace@ietf.org> 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 <i...@augustcellars.com <mailto:i...@augustcellars.com> > 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? 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. 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. [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 Ace@ietf.org <mailto:Ace@ietf.org> https://www.ietf.org/mailman/listinfo/ace
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
