Hannes, I’ll clarify the software statement and let Mike/Justin respond for the rest.
Phil @independentid www.independentid.com phil.h...@oracle.com On Jun 5, 2014, at 12:42 AM, Hannes Tschofenig <hannes.tschofe...@gmx.net> wrote: > Hi Justin, Hi Mike, > > thanks for updating the document so quickly. > > I have re-read the new version and I have a few minor comments. > > You write: "The following client metadata fields are defined by this > specification. All client metadata fields are OPTIONAL." > > I guess you mean "Optional to implement and optional to use.". Maybe it > would be good to state that. > > In the terminology section you briefly introduce a number of actors and > concepts. The description for the initial access token and the software > statement is somewhat short. > > I am particularly interested to learn who issues the initial access > token and the software statement? What is the purpose? What does it > authorize? These tokens have very different characteristics. The Software Statement is not a security token. It is a statement that locks the registration profile for client software and provides AS endpoints with a way to recognize client software since they do not have a client_id yet. In practical terms, AS endpoints can set policy to automatically approve reject based on specific statement, or content rules (software_id, version etc) or even approve based on the signer of the statements (e.g. allow registration for any client software statement signed by Cisco). Typically, the statement would be generated once (for all copies distributed) by the developer, publisher, or a collective organization. This is particularly useful when the publisher of an API is not the same organization as the deployers of the actual API endpoints following a common open API specification. For example, OpenID Connect would be one such example. In the early OAuth1 and 2 days, most use cases had the API publisher and the deployer as the same organization. A client_id could be issued in advance and could be used as both credential id and software identifier. In the evolving world, we have lots of cases (e.g. OpenID Connect) where the organization that defines the API specification is not the same as the one operating implementations of the API specification. Client_id can’t serve both purposes. Software statement fills the gap allowing client software to use a client statement “claim” that can be “exchange” for a deployment assigned client_id. Initial access token is a security token that allows the client to register in a closed/restricted registration endpoint where anonymous registration may not be allowed. Useful in some environments where an IT organization might re-package a client for distribution on an internal or private system. Where the software statement is issued by either the developer or the API specification organization, the initial access token is typically issued by the “domain” (or an organization affiliated with it) where the client intends to register. —> have I got that correctly justin? > > I still don't fully get the idea of having both tokens (the initial > access token and the software assertion). Stating who issues those might > clarify it. If different parties provide different statements or grant > different authorization rights based on these two "tokens" then I am > happy but with the current write-up I feel that there is something missing. > > Redirect URIs: The text says: > "It is RECOMMENDED that clients using these flows register this > parameter, and an authorization server SHOULD require registration of > valid redirect URIs for all clients that use these grant types to > protect against token and credential theft attacks." > > The security consideration section is equally weak: > "For clients that use redirect-based grant types such as > authorization_code and implicit, authorization servers SHOULD require > clients to register their redirect_uris in full." > > Shouldn't the recommendation be a bit stronger particularly in light of > the recently discussed covered redirect attack? > > What happens if the client does not provide any redirect uris? I > recommend to avoid the SHOULD because it is nothing a protocol > specification can fulfill. It seems to be rather a policy issue. I think > there should also be a description about "full" means here as well. For > example, would the AS be expected to understand something like > https://*.example.com? > > MUST, MAY, SHOULDs: I think that the document still uses RFC 2119 > language too excessively at places where it does not provide any > guidance for protocol implementers. I would recommend to carefully > re-read each MUST/MAY/SHOULD and judge whether it imposes any > implementation specific requirements and if it doesn't to replace it > with deployment recommendations instead. Also, if there is a SHOULD then > it should be clear to the reader under what circumstances what action > should be taken. > > policy_uri: In my previous review I argued that the right terminology > here is privacy notice and you can even re-use the IAPP terminology. > Unless the policy URI has nothing to do with privacy I would prefer this > terminology change. If you disagree I would prefer to have a > description about what policy means in this context. > > jwks: my problem with the fuzzy description is that it is not indicated > how the client (or any other party) would reference the listed keys and > what these would be used for. Maybe this document is not the right place > to define these JWKs if the semantic cannot be defined properly. > > Regarding the ‘software_id' definition. You write that the software_id > is asserted by the client software but wouldn't it be more reasonable > that some human (in an organization) asserts something rather than > software. The software just acts on behalf of the human. Would it be > reasonable to say that a client developer makes these assertions. > > Regarding Section 4.2 client registration error response: Does a > response message always contain two members, namely error and > error_description? I would argue that the error member must be there but > the error_description is optional. > > Regarding the error values I am missing a value that allows the > authorization server that a specific field has to be provided and is > currently absent. > > Ciao > Hannes > > > _______________________________________________ > 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
