Hi. Thanks for the detailed comments. Here are the responses to the questions raised in [1]
[1] http://www.tschofenig.priv.at/oauth/draft-ietf-oauth-spop-00-hannes.doc 3.1 [Question: Would it make sense to provide some information also in the > Dynamic Client Registration specification? I am a bit unhappy about not > specifying at least one mechanism for learning this information since it is > important for the overall security -- to avoid downgrading attacks.] I would have included it if OAuth has defined a discovery document. n fact, it may be a good starting point to discuss whether we should have a discovery document for OAuth. If the client does the per client registration, then it will not be a public client so spop would not be needed. The clients as a class may register itself, but then each client instance would not know if the server knows that it is using spop, and assuming it without verifying is not very safe. 3.1 [Hannes: Can we make a more explicit reference to a feature in the > OpenID Connect Discovery specification?] It will be an extension to section 3 of OpenID Connect Discovery. This specification may define a JSON name for such a parameter. Then, one can include it in the metadata. A candidate for such name would be: oauth_spop_supported_alg: and the value would be the strings representing supported algorithms. It could be drawn from JWA algs. A simpler alternative would be: oauth_spop_support: and the value would be true or false. However, we have no good place to advertise them as of now. 3.2 [Hannes: Do we really need this flexibility here?] It is there as an extension point. John has a draft that uses aymmetric algo. An early draft had HMAC as well. We could however drop it. I suppose we can add other algorithms later without breaking this one. [Hannes: The term 'front channel' is not defined anywhere.] Will define if this section survives. 3.7 [Hannes: Why is there a SHOULD rather than a MUST?] The server may have other considerations before returning successful response. 5. [Hannes: Which request channel are you talking about? There are two > types of request channels here, namely the Access Token Request/Response > and the Authorization Request / Response channel. What do you mean by > adequately protected here? How likely is it that this can be accomplished? > If it is rather unlikely then it would be better to define a different > transformation algorithm!] This is referring to the authorization request. On iOS as of the time of writing, not Jailbreaking seems to be adequate. For Android, only presenting the intended browser as the options to handle the request seems adequate. Similar considerations would be there per platform. Note: Authors do think that using other algorithms is better. However, it proved to be rather unpopular among the developers that they were in touch with and believe that we do need to provide this "no-transform" capability. For other "corrections", I am still working on to prepare comments as word comments. Most of editorial changes will be accepted. Some proposed technical changes seems to be due to the clauses being unclear, so I will try to propose a clarification rather than just accepting them. Best, Nat 2014-08-29 16:13 GMT+09:00 Hannes Tschofenig <[email protected]>: > > Hi John, Hi Nat, > > I went through the document in detail and suggest some changes (most of > them editorial): > http://www.tschofenig.priv.at/oauth/draft-ietf-oauth-spop-00-hannes.doc > http://www.tschofenig.priv.at/oauth/draft-ietf-oauth-spop-00-hannes.pdf > > My main concern at the moment are some optional features in the spec > that make it less interoperable, such as the feature discovery, and the > transformation function. The latter might go away depending on your > answer to my question raised at > http://www.ietf.org/mail-archive/web/oauth/current/msg13354.html but the > former requires some specification work. > > Ciao > Hannes > > PS: I agree with James that the title of the document is a bit > misleading when compared with the other work we are doing in the group. > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
