[OAUTH-WG] Define a server capaiblity discovery parameter? (was: Re: OAuth SPOP Detailed Review)

[Nat Sakimura <[e-mail]>]

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 <[e-mail]> 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
> <[e-mail]>:
> >
> > 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> 
> 
> 
> --
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en


-- 
Nat Sakimura ([e-mail])
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.