Phil @independentid www.independentid.com phil.h...@oracle.com
> On Feb 11, 2015, at 8:31 PM, Justin Richer <jric...@mit.edu> wrote: > > Kathleen, thanks for the review. Responses inline, though I'm going to let > the other authors talk about their sections (deployment org, software > version, etc) directly. > > On 2/11/2015 6:06 PM, Kathleen Moriarty wrote: >> Thank you for your work on this draft and sorry for the delay in my review. >> Before we progress to IETF last call, I'd like to see what we can resolve >> from the list below. I am looking at the IPR issues to see if we can >> resolve the outstanding questions as well. >> >> The Shepherd report says the following: >> The document shepherd has raised concerns regarding the fuzzy description >> of the actors (deployment organization, software API publisher, client >> developer) and their impact on the protocol execution. The working >> group did not seem to worry about these aspects though. >> >> I can see the point after reading the draft. The interactions are written >> much more clearly in the security considerations section than where the >> flows are described. Can something be done to address these concerns? >> >> Section 1.2 >> Deployment Organization definition: >> I highly recommend replacing the phrase "simple cloud deployment" with a >> description that accurately reflects what is intended. If that's within a >> single service provider's network, a single data center, or a single hosted >> data center, I think it would be more clear. >> >> Section 1.2 nit: >> Add the word "be" into the following term definition after "may": >> Software API Publisher >> The organization that defines a particular web accessible API that >> may deployed in one or more deployment environments. > > [deferred to original author of this text Phil et. al for better wording] [Phil] Agreed with Kathleen’s suggestion. > >> >> Section 2: >> >> Why isn't a more secure option offered and set as the default for >> authentication types? I know I've asked this before and the answer was just >> that you can add something to the registry, but setting HTTP Basic as the >> default seems like a really bad choice. HOBA is on it's way to becoming an >> RFC from the HTTPAuth working group. HTTPAuth also has an updated version >> of Basic that is in IETF last call, but I know you are pointing to the OAuth >> 2.0 document, so it would be that document that gets updated and not this >> draft. The new version of HTTP Basic fixes some internationalization >> problems and spells out the security issues much more clearly, so it >> probably doesn't matter too much to update the reference, but maybe makes it >> more clear that basic is not a secure form of authentication. >> >> Can you provide some justification as to why this is okay to set basic as >> the default and add that to the draft? Section 2.3.1 of OAuth 2.0 just says >> this MUST be implemented, but that any HTTP schemes can be used. Why not >> register another method and use that instead as the default? You could use >> digest and there is library support. It's not a great answer, but slightly >> better than passwords with basic. You could register HOBA and use that >> instead, the only downside is limited library support at the moment. > > It was our intent to document the methods already defined for use with OAuth > and provide a registration mechanism for distinguishing between them, not to > create new client authentication mechanisms. Digest and HOBA simply aren't > defined for use with OAuth clients yet. It would be simple to do: put the > client id in the "username" field and the client secret in the "password" > field of both algorithms. However, I don't believe it's a good idea to > conflate those two goals in a single specification. We actually had other, > more secure definitions in an earlier draft of this document (using a JWT > signed with a private key or a JWT signed with a shared key, specifically), > but those were removed in order to focus on solving just the client > registration problem. I agree with that decision of the WG. > > As other methods of client authentication are defined in the OAuth ecosystem, > they can register as valid values in the registry. I think it would be a > valuable output of this WG to define other client authentication mechanisms > as a separate draft or an eventual update to RFC6749 (or both?). > >> >> Section 2: Contacts: >> >> I noticed privacy is not dealt with until you get to the security >> considerations section. I'd prefer to see it with the definition, stating >> the address should be a general help address at the domain rather than >> directly to an identifiable individual. It may be good to set a default for >> what this should be for consistency or give an example (think back to >> ab...@domain.com <mailto:ab...@domain.com>)? > > The problem that I see with putting it inside the definition is that it makes > the definition text very long, as the definition sits in a list of other > metadata items. We could add a forward pointer and an example easily enough, > though. Or we could move the privacy considerations section up as a > subsection here, though I don't know if that runs afoul of the RFC style > guidelines for this new section. > >> >> Software_id and software_version: >> Are there any guidelines as to how these should be represented? There are >> several specifications on software_id (and platform). Does consistency here >> matter or is this just meant to be human readable? >> Section 2.2 specifies some metadata values that are to be human readable, >> should the above be in the list? I would expect this list to be >> comprehensive for clarity, rather than just examples since there aren't too >> many defined here. >> > > [mostly deferred to Phil et. al, but note that software_id and > software_version are not intended to be human readable and don't need the > multi-language support] [Phil] I’ve added some more explanatory text. Note…some of this may be better put elsewhere. As to whether the values are human readable, I have no opinion. What matters most is unique matching. software_id A unique identifier (e.g. UUID) assigned by the developer or software publisher used by registration endpoints to identify client software to be dynamically registered. Unlike "client_id", which is issued by the authorization server and varies between instances of software, the "software_id” SHOULD remain the same for all client software instances. The “software_id” SHOULD remain the same across multiple software updates or versions. software_version A version identifier for the software identified by “software_id". The value of this field is a string that is intended to be compared using string equality matching. Unlike “software_id”, the value of the "software_version" SHOULD change on any update to the client software. A service provider MAY use “software_id" and “software_version" to recognize approved software and version combinations approved for dynamic registration. Let me know if you want more background. > >> Section 3.2.1 & Privacy section >> For client_name and client_id and associated information, how is user >> privacy affected and what can be done to mitigate concerns? The definition >> should state that this is a public value and that it is specific to the >> software, not a person. You have to get to the security consideration >> section before that is clear. References are fine too, but some more >> information is needed in the privacy section. I'm left with a bunch of >> questions: >> Can the client_name and client_id be tied to a person? > The client name is common across all copies of the software (usually), so no > worries there. The ID represents an individual piece of software, not a > person, though if that person is the sole user of the instance of software > then I believe you're right that there are some privacy considerations that > we should point that out. However, dynamic registration can actually help > mitigate this as well, since in the normal case (with no software statements) > there's no way to correlate instances of clients with each other. >> Can the person be tracked by this? >> Can other information be gathered about a system (and it's user) during >> this process? > Nothing gathered about the user during registration, as this happens in the > back channel outside the user's purview. >> The information is used to dynamically register clients, what is logged? >> What data is aggregated? >> What can you tell about a client (time, location, travel, other personal >> details that may be considered sensitive)? I don't think this was covered >> in the OAuth 2.0 RFC. >> How is this addressed at the authorization server and other points? >> The Security considerations talks about client_id as being short lived, so >> they expire, but are these event logged or is that prohibited? > > Many of these questions seem to be completely dependent on the implementation > of the authorization server, and I'm not really sure how (or if) to address > them in this draft. Any suggestions would be welcomed here. > > The client_id *could* be short lived, but they usually aren't. I don't see > any particular logging or tracking concerns using a dynamic OAuth client > above using any other piece of software, ever. As such, I don't think it > requires special calling out here. > >> >> 5. Security considerations >> The first paragraph is a repeat of text. Can this just be in one place and >> use a pointer to the full text? I like the requirement, but reading it once >> is enough. > > I think it was less onerous of a repeat when both simply said "use TLS", so > some refactoring after the expansion of the text makes sense to me. Would it > be better to have it upfront in the endpoint definition, or in the security > considerations? > >> >> -- >> >> Best regards, >> Kathleen > > Thanks again for your review! > > -- Justin > >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
