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.
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.
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)?
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.
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?
Can the person be tracked by this?
Can other information be gathered about a system (and it's user) during
this process?
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?
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.
--
Best regards,
Kathleen
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
