I started to draft the change. If you send me what you have I will incorporate it.
Sent from my iPhone > On Oct 20, 2014, at 3:34 AM, Nat Sakimura <n-sakim...@nri.co.jp> wrote: > > 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 <wdenn...@google.com>: >> 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 <n-sakim...@nri.co.jp> 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 <sakim...@gmail.com> 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 >>> > <hannes.tschofe...@gmx.net>: >>> > > >>> > > 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 >>> > > OAuth@ietf.org >>> > > https://www.ietf.org/mailman/listinfo/oauth >>> > > >>> > >>> > >>> > >>> > -- >>> > Nat Sakimura (=nat) >>> > Chairman, OpenID Foundation >>> > http://nat.sakimura.org/ >>> > @_nat_en >>> >>> >>> -- >>> Nat Sakimura (n-sakim...@nri.co.jp) >>> 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 >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > > > -- > Nat Sakimura (=nat) > http://www.sakimura.org/en/ > http://twitter.com/_nat_en > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
