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

From: Nat Sakimura <[email-masked]>
Date: Tue, 14 Oct 2014 18:19:31 +0900

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

-- 
Nat Sakimura ([email-masked])
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.

---

From: William Denniss <[email-masked]>
Date: Sun, 19 Oct 2014 23:19:52 -0700

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-masked]> wrote:

> In his mail, Hannes suggested to include more explicit reference to a
> feature in the OpenID Connect Discovery spec in section 3.1.
>

---

From: Nat Sakimura <[email-masked]>
Date: Mon, 20 Oct 2014 15:34:52 +0900

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!

-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en

---

From: John Bradley <[email-masked]>
Date: Mon, 20 Oct 2014 08:03:04 -0300

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 <[email-masked]> 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!
> 
>> 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.
>> 
>>

---

From: William Denniss <[email-masked]>
Date: Mon, 20 Oct 2014 22:28:31 -0700

I merged my proposed changes with Nat's recent 01 draft, my pull request
(and diff) is here:
https://bitbucket.org/Nat/oauth-spop/pull-request/1/specified-exactly-two-code-transformation/diff

TXT and PDF exports available for viewing from here:
https://bitbucket.org/wdenniss/oauth-spop/downloads

Let me know what you think. This proposed draft suggests two and only two
transformation algorithms: plain and SHA-256.  I think that simplifies the
spec considerably, while still achieving everything it sets out to do.

On Mon, Oct 20, 2014 at 4:03 AM, John Bradley <[email-masked]> wrote:

>> I vote that we don't want discovery at all, as it adds a lot of
>> complexity while yielding little to no benefit.
>>
>> Due to the short window of time for code redemption, the hashing
>> algorithm would have to be *seriously* broken to be unusable for spop.
>>