That would be great. Actually, several stakeholders informed me that they would like sha256 transformation as well. Either John B. or I was supposed draft it but we have not to the date, so a draft wording would be great.
Thanks! 2014-10-20 15:19 GMT+09:00 William Denniss <[email protected]>: > 1) n. > > I vote that we don't want discovery at all, as it adds a lot of complexity > while yielding little to no benefit. > > I think we should support 2 transformations, plain (as mandated by the > spec), and the best hashing algorithm that is commonly available (i.e. > SHA256). If the spec needs to be updated in the future for a newer, better > algorithm, a revised version of the spec could be created then. > > Due to the short window of time for code redemption, the hashing algorithm > would have to be *seriously* broken to be unusable for spop. > > If this sounds good, I have a some draft wording with the above changes > that could be incorporated. > > > On Tue, Oct 14, 2014 at 2:19 AM, Nat Sakimura <[email protected]> > wrote: > >> In his mail, Hannes suggested to include more explicit reference to a >> feature in the OpenID Connect Discovery spec in section 3.1. >> >> My response to it was that we could define a parameter here >> and ask the implementers to implement it. Questions remains whether >> we want to define it here or leave it to be out of scope. >> >> So, my questions are: >> >> (1) Do we want it? (y or n) >> (2) if y, then adding the following text at the end of 3.1 be adequate? >> >> When the server supports OpenID Connect Discovery 1.0, the server MUST >> advertise its capability with a parameter >> <spanx style="verb">oauth_spop_supported_alg</spanx>. >> The value of it is a JSON array of JSON strings representing >> "alg" (Algorithm) Header Parameter Values for JWS as defined in >> <xref target="JWA">JSON Web Algorithms</xref>. >> >> Nat >> >> On Wed, 3 Sep 2014 02:28:57 +0900 >> Nat Sakimura <[email protected]> wrote: >> >> > 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 >> >> >> -- >> Nat Sakimura ([email protected]) >> Nomura Research Institute, Ltd. >> >> 本メールに含まれる情報は機密情報であり、宛先に記載されている方のみに送信 >> することを意図しております。意図された受取人以外の方によるこれらの情報の >> 開示、複製、再配布や転送など一切の利用が禁止されています。誤って本メール >> を受信された場合は、申し訳ございませんが、送信者までお知らせいただき、受 >> 信されたメールを削除していただきますようお願い致します。 PLEASE READ: >> The information contained in this e-mail is confidential and intended >> for the named recipient(s) only. If you are not an intended recipient >> of this e-mail, you are hereby notified that any review, dissemination, >> distribution or duplication of this message is strictly prohibited. If >> you have received this message in error, please notify the sender >> immediately and delete your copy from your system. >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth >> > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > -- Nat Sakimura (=nat) http://www.sakimura.org/en/ http://twitter.com/_nat_en
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
