Re: [OAUTH-WG] Define a server capaiblity discovery parameter? (was: Re: OAuth SPOP Detailed Review)
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 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 : >> 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 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 >>> oauth_spop_supported_alg. >>> The value of it is a JSON array of JSON strings representing >>> "alg" (Algorithm) Header Parameter Values for JWS as defined in >>> JSON Web Algorithms. >>> >>> Nat >>> >>> On Wed, 3 Sep 2014 02:28:57 +0900 >>> Nat Sakimura 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!] >>> > >>>
Re: [OAUTH-WG] Define a server capaiblity discovery parameter? (was: Re: OAuth SPOP Detailed Review)
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 : > 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 > 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 >> oauth_spop_supported_alg. >> The value of it is a JSON array of JSON strings representing >> "alg" (Algorithm) Header Parameter Values for JWS as defined in >> JSON Web Algorithms. >> >> Nat >> >> On Wed, 3 Sep 2014 02:28:57 +0900 >> Nat Sakimura 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:
[OAUTH-WG] Define a server capaiblity discovery parameter? (was: Re: OAuth SPOP Detailed Review)
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 oauth_spop_supported_alg. The value of it is a JSON array of JSON strings representing "alg" (Algorithm) Header Parameter Values for JWS as defined in JSON Web Algorithms. Nat On Wed, 3 Sep 2014 02:28:57 +0900 Nat Sakimura 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 > : > > > > 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 > > >
