Re: [OAUTH-WG] Symmetric Proof of Possession for the OAuth Authorization Code Grant: comments
I support the use of public key. As I remember, our discussion started
there.
I still believe this is something that is needed to be standardized.
However, for spop use case, we have determined that is overkill and best
left for another draft.
It looks like there is a strong support in the thread to droop the
transform.
I have not heard any strong desire to keep the extensibility.
If any of you do, please voice it now.
Otherwise, I will drop the transform related clauses from the next rev.
Nat
2014-09-03 5:17 GMT+09:00 John Bradley :
> I don't think the inclusion of a MAC transform to protect the request is
> necessary for it to be called proof of possession.
>
> The other way to protect the request is with a signed/encrypted request
> object. That is heaver weight than the HMAC transform.
>
> I may have come up with the trick of sending the hmac in the request and
> the key as the proof, so am a bit partial to it.
>
> On the other hand I don't know that the incremental value is that much.
>
> It may be better to skip that and add a way for a client to specify it's
> public key (JWK) as part of it's authorization request to the AS.
>
> I see that more as part of the full OAuth PoP spec for access tokens.
>
> That way the access tokens would also be bound to the client.
>
> That would let us keep SPOP for code as simple as possible.
>
> John B.
>
> On Sep 2, 2014, at 2:32 PM, Nat Sakimura wrote:
>
> Hi James and Brian,
>
> First, I apologize for taking a long time to respond to James.
>
> My responses inline:
>
>
> 2014-09-03 2:49 GMT+09:00 Brian Campbell :
>
>> On #1, I know some have pushed for having the transformation options so I
>> don't know if dropping it will work. But, if not removed entirely, the
>> transformation stuff could definitely be deemphasized in favor of what will
>> be the most common case of the client sending a random string value on the
>> authorization request and then sending the same value on the token request.
>>
>
> Indeed, there have been some lengthy discussions around it, so I have not
> removed them.
> However, if the WG feels that it is ok to leave them out, I am fine with
> it.
> It would impact the name of the spec though, as it will not be PoP
> anymore.
> The justification for using PoP in the name is that in non-degenerate
> case, it is a PoP.
>
>
>>
>> On #2, there are already implementations and deployments of this so I'd
>> request that the parameter names not be changed.
>>
>
> Noted.
>
>
>>
>> On #3, I agree that the title is confusing/misleading. Perhaps, "Request
>> Correlation for the OAuth Authorization Code Grant" or something like that?
>>
>
> See #1.
>
>
>>
>> On #4, on one hand you are right. On the other hand, this is the OAuth WG
>> and this draft is addressing a very specific security issue in OAuth
>> deployments. Having it be OAuth-centric seems right given the circumstances.
>>
>
> IMHO, this is a scoping issue. The current draft is scoped to solve a
> specific problem of OAuth public clients.
> More generic way can obviously be envisaged, but I am not sure if it is
> something to be worked on within OAuth WG.
>
> Nat
>
>
>>
>>
>>
>>
>> On Thu, Aug 28, 2014 at 11:03 PM, Manger, James <
>> james.h.man...@team.telstra.com> wrote:
>>
>>> Couple of comments on draft-ietf-oauth-spop-00:
>>>
>>> The draft defines a nice little mechanism to link two requests: one from
>>> app-to-browser-to-server, the other from app-to-server.
>>>
>>> 1.
>>> The spec defines the "bearer token" version of linking the requests:
>>> pick a random value and send it in both requests. The spec repeatedly hints
>>> that other "transformations" are possible (and even mentions one in a
>>> note), but it doesn't define enough to make these other ones interoperable.
>>> I suggest just specifying the bearer version and dropping all the other
>>> text.
>>> If we want another transform standardized later then we write another
>>> spec (which can use its own field names).
>>>
>>> 2.
>>> Linking requests is orthogonal to whether or not the requests include a
>>> field called "code". I suggest changing the labels "code_challenge" and
>>> "code_verifier" to drop the "code" reference. Perhaps replace both with
>>> "session_id" ("sid" for short?).
>>>
>>> 3.
>>> The spec is titled "Symmetric Proof of Possession ..." but defines a
>>> bearer mechanism, which you cannot really classify as proof-of-possession.
>>> Suggestion: change the title.
>>>
>>> 4.
>>> The text is totally OAuth-centric, though the mechanism is not really
>>> limited to this case. It would be much nicer to describe the mechanism more
>>> generically (eg app running on a user's computer wanting to link two
>>> requests made to a server over different channels). The abstract (and the
>>> start of the introduction) should be comprehensible without having to know
>>> what the phrase "OAuth 2.0 public client" means. There would still be some
>>> OAuth-specific sections describing how the mechanism applies to the code
>>
Re: [OAUTH-WG] Symmetric Proof of Possession for the OAuth Authorization Code Grant: comments
I don't think the inclusion of a MAC transform to protect the request is
necessary for it to be called proof of possession.
The other way to protect the request is with a signed/encrypted request object.
That is heaver weight than the HMAC transform.
I may have come up with the trick of sending the hmac in the request and the
key as the proof, so am a bit partial to it.
On the other hand I don't know that the incremental value is that much.
It may be better to skip that and add a way for a client to specify it's public
key (JWK) as part of it's authorization request to the AS.
I see that more as part of the full OAuth PoP spec for access tokens.
That way the access tokens would also be bound to the client.
That would let us keep SPOP for code as simple as possible.
John B.
On Sep 2, 2014, at 2:32 PM, Nat Sakimura wrote:
> Hi James and Brian,
>
> First, I apologize for taking a long time to respond to James.
>
> My responses inline:
>
>
> 2014-09-03 2:49 GMT+09:00 Brian Campbell :
> On #1, I know some have pushed for having the transformation options so I
> don't know if dropping it will work. But, if not removed entirely, the
> transformation stuff could definitely be deemphasized in favor of what will
> be the most common case of the client sending a random string value on the
> authorization request and then sending the same value on the token request.
>
> Indeed, there have been some lengthy discussions around it, so I have not
> removed them.
> However, if the WG feels that it is ok to leave them out, I am fine with it.
> It would impact the name of the spec though, as it will not be PoP anymore.
> The justification for using PoP in the name is that in non-degenerate case,
> it is a PoP.
>
>
> On #2, there are already implementations and deployments of this so I'd
> request that the parameter names not be changed.
>
> Noted.
>
>
> On #3, I agree that the title is confusing/misleading. Perhaps, "Request
> Correlation for the OAuth Authorization Code Grant" or something like that?
>
> See #1.
>
>
> On #4, on one hand you are right. On the other hand, this is the OAuth WG and
> this draft is addressing a very specific security issue in OAuth deployments.
> Having it be OAuth-centric seems right given the circumstances.
>
> IMHO, this is a scoping issue. The current draft is scoped to solve a
> specific problem of OAuth public clients.
> More generic way can obviously be envisaged, but I am not sure if it is
> something to be worked on within OAuth WG.
>
> Nat
>
>
>
>
>
> On Thu, Aug 28, 2014 at 11:03 PM, Manger, James
> wrote:
> Couple of comments on draft-ietf-oauth-spop-00:
>
> The draft defines a nice little mechanism to link two requests: one from
> app-to-browser-to-server, the other from app-to-server.
>
> 1.
> The spec defines the "bearer token" version of linking the requests: pick a
> random value and send it in both requests. The spec repeatedly hints that
> other "transformations" are possible (and even mentions one in a note), but
> it doesn't define enough to make these other ones interoperable.
> I suggest just specifying the bearer version and dropping all the other text.
> If we want another transform standardized later then we write another spec
> (which can use its own field names).
>
> 2.
> Linking requests is orthogonal to whether or not the requests include a field
> called "code". I suggest changing the labels "code_challenge" and
> "code_verifier" to drop the "code" reference. Perhaps replace both with
> "session_id" ("sid" for short?).
>
> 3.
> The spec is titled "Symmetric Proof of Possession ..." but defines a bearer
> mechanism, which you cannot really classify as proof-of-possession.
> Suggestion: change the title.
>
> 4.
> The text is totally OAuth-centric, though the mechanism is not really limited
> to this case. It would be much nicer to describe the mechanism more
> generically (eg app running on a user's computer wanting to link two requests
> made to a server over different channels). The abstract (and the start of the
> introduction) should be comprehensible without having to know what the phrase
> "OAuth 2.0 public client" means. There would still be some OAuth-specific
> sections describing how the mechanism applies to the code flow (and to
> register a field in the IANA OAuth registry).
>
>
> --
> James Manger
>
> ___
> 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)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_
Re: [OAUTH-WG] Symmetric Proof of Possession for the OAuth Authorization Code Grant: comments
Hi James and Brian,
First, I apologize for taking a long time to respond to James.
My responses inline:
2014-09-03 2:49 GMT+09:00 Brian Campbell :
> On #1, I know some have pushed for having the transformation options so I
> don't know if dropping it will work. But, if not removed entirely, the
> transformation stuff could definitely be deemphasized in favor of what will
> be the most common case of the client sending a random string value on the
> authorization request and then sending the same value on the token request.
>
Indeed, there have been some lengthy discussions around it, so I have not
removed them.
However, if the WG feels that it is ok to leave them out, I am fine with
it.
It would impact the name of the spec though, as it will not be PoP anymore.
The justification for using PoP in the name is that in non-degenerate case,
it is a PoP.
>
> On #2, there are already implementations and deployments of this so I'd
> request that the parameter names not be changed.
>
Noted.
>
> On #3, I agree that the title is confusing/misleading. Perhaps, "Request
> Correlation for the OAuth Authorization Code Grant" or something like that?
>
See #1.
>
> On #4, on one hand you are right. On the other hand, this is the OAuth WG
> and this draft is addressing a very specific security issue in OAuth
> deployments. Having it be OAuth-centric seems right given the circumstances.
>
IMHO, this is a scoping issue. The current draft is scoped to solve a
specific problem of OAuth public clients.
More generic way can obviously be envisaged, but I am not sure if it is
something to be worked on within OAuth WG.
Nat
>
>
>
>
> On Thu, Aug 28, 2014 at 11:03 PM, Manger, James <
> james.h.man...@team.telstra.com> wrote:
>
>> Couple of comments on draft-ietf-oauth-spop-00:
>>
>> The draft defines a nice little mechanism to link two requests: one from
>> app-to-browser-to-server, the other from app-to-server.
>>
>> 1.
>> The spec defines the "bearer token" version of linking the requests: pick
>> a random value and send it in both requests. The spec repeatedly hints that
>> other "transformations" are possible (and even mentions one in a note), but
>> it doesn't define enough to make these other ones interoperable.
>> I suggest just specifying the bearer version and dropping all the other
>> text.
>> If we want another transform standardized later then we write another
>> spec (which can use its own field names).
>>
>> 2.
>> Linking requests is orthogonal to whether or not the requests include a
>> field called "code". I suggest changing the labels "code_challenge" and
>> "code_verifier" to drop the "code" reference. Perhaps replace both with
>> "session_id" ("sid" for short?).
>>
>> 3.
>> The spec is titled "Symmetric Proof of Possession ..." but defines a
>> bearer mechanism, which you cannot really classify as proof-of-possession.
>> Suggestion: change the title.
>>
>> 4.
>> The text is totally OAuth-centric, though the mechanism is not really
>> limited to this case. It would be much nicer to describe the mechanism more
>> generically (eg app running on a user's computer wanting to link two
>> requests made to a server over different channels). The abstract (and the
>> start of the introduction) should be comprehensible without having to know
>> what the phrase "OAuth 2.0 public client" means. There would still be some
>> OAuth-specific sections describing how the mechanism applies to the code
>> flow (and to register a field in the IANA OAuth registry).
>>
>>
>> --
>> James Manger
>>
>> ___
>> 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)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Symmetric Proof of Possession for the OAuth Authorization Code Grant: comments
On #1, I know some have pushed for having the transformation options so I
don't know if dropping it will work. But, if not removed entirely, the
transformation stuff could definitely be deemphasized in favor of what will
be the most common case of the client sending a random string value on the
authorization request and then sending the same value on the token request.
On #2, there are already implementations and deployments of this so I'd
request that the parameter names not be changed.
On #3, I agree that the title is confusing/misleading. Perhaps, "Request
Correlation for the OAuth Authorization Code Grant" or something like that?
On #4, on one hand you are right. On the other hand, this is the OAuth WG
and this draft is addressing a very specific security issue in OAuth
deployments. Having it be OAuth-centric seems right given the circumstances.
On Thu, Aug 28, 2014 at 11:03 PM, Manger, James <
james.h.man...@team.telstra.com> wrote:
> Couple of comments on draft-ietf-oauth-spop-00:
>
> The draft defines a nice little mechanism to link two requests: one from
> app-to-browser-to-server, the other from app-to-server.
>
> 1.
> The spec defines the "bearer token" version of linking the requests: pick
> a random value and send it in both requests. The spec repeatedly hints that
> other "transformations" are possible (and even mentions one in a note), but
> it doesn't define enough to make these other ones interoperable.
> I suggest just specifying the bearer version and dropping all the other
> text.
> If we want another transform standardized later then we write another spec
> (which can use its own field names).
>
> 2.
> Linking requests is orthogonal to whether or not the requests include a
> field called "code". I suggest changing the labels "code_challenge" and
> "code_verifier" to drop the "code" reference. Perhaps replace both with
> "session_id" ("sid" for short?).
>
> 3.
> The spec is titled "Symmetric Proof of Possession ..." but defines a
> bearer mechanism, which you cannot really classify as proof-of-possession.
> Suggestion: change the title.
>
> 4.
> The text is totally OAuth-centric, though the mechanism is not really
> limited to this case. It would be much nicer to describe the mechanism more
> generically (eg app running on a user's computer wanting to link two
> requests made to a server over different channels). The abstract (and the
> start of the introduction) should be comprehensible without having to know
> what the phrase "OAuth 2.0 public client" means. There would still be some
> OAuth-specific sections describing how the mechanism applies to the code
> flow (and to register a field in the IANA OAuth registry).
>
>
> --
> James Manger
>
> ___
> 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
