Hi Mike, thanks for responding also to the question about dynamic client registration.
I also believe it would be useful to add information in the draft about the opaqueness nature of the different tokens, i.e., who is supposed to read them. From the current wording of the document my understanding was that the OAuth client does not need to parse the initial access token nor the software statement. It just relays it. If the client indeed has to parse the software statement then it would be good to know why this is done and what the client uses the information for. As mentioned in my review comments I think it would be helpful for the reader to state who creates and distributes these tokens (as you and Phil) have explained in the email. Put those thoughts into the document. Ciao Hannes On 06/05/2014 09:18 PM, Mike Jones wrote: > The answer to your question about the Initial Access Token and > Software Statement is highly parallel to the answer to your question > in the other thread about the Access Token and ID Token. :-) The > Initial Access Token and the Software Statement do quite different > things and have different structures and properties. The Initial > Access Token is an opaque value that grants access to the > registration resource. A Software Statement is a non-opaque JWT > security token that makes claims about the software being registered. > You can have one without the other or you can have both, depending > upon the use case. > > The parties that issue the two are also different. The Initial > Access Token is issued by and is about access to the Authorization > Server. The Software Statement is issued by the author of the > Client, or a party cooperating with the author, and is about the > Client. Both their authorship and subject matter of the two data > structures are different. > > -- Mike > > -----Original Message----- From: OAuth > [mailto:[email protected]] On Behalf Of Hannes Tschofenig Sent: > Thursday, June 05, 2014 12:42 AM To: [email protected] Subject: > [OAUTH-WG] draft-ietf-oauth-dyn-reg-17 review > > 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? > > 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 > >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
