Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

[Kathleen Moriarty]

Sent from my iPhone

> On Nov 20, 2015, at 2:53 PM, John Bradley  wrote:
> 
> I don’t know of any special requirements for representing HSM keys.   

I wasn't suggesting that there were separate requirements or different key 
types as that would not be the case, just that the discussions did not seem to 
be complete. 
> 
> How they are negotiated and stored is out of scope for this draft.
> 
> I think Brian mentioned that we had an example that is different from the 
> default in the POP drafts.   That can be looked at.
> 
> I don’t think we want to get into key management.  That should be left to 
> specifications that use this.
> 
> Chuck’s example gets into proof mechanisms for token presentment.
> That is also out of scope for this draft.   There are two mechanisms as part 
> of the POP specs.

Ok, sounds good.  Thanks.

> One is mutual TLS and the other is using a signed message.  
> I think the signed message one is what he is looking for.  
> https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-01
> 
> I suppose that you could over sign the token itself but there are perhaps 
> better ways to do it.
> So if wrapping rules are needed that would probably be part of a pop token 
> proof presentment spec.

Ok, thanks.
Kathleen 
> 
> 
> John B.
> 
>> On Nov 20, 2015, at 4:32 PM, Mike Jones  wrote:
>> 
>> HSM-backed public keys would be represented in the same way that other 
>> public keys are - using the standard JWK representation for them.  Likewise 
>> for TPM-backed public keys.  That said, I'm not an expert in TPMs and know 
>> that they define TPM-specific signature formats but to my understanding, 
>> they're using standard kinds of keys.  If this isn't the case, a new key 
>> type ("kty") would be needed to represent them, but they'd still be 
>> represented as a JWK in the JWT using that key type.  The draft would still 
>> work fine for these use cases as written.  Does that sound right to people 
>> or am I missing something here?
>> 
>> For Chuck's nested JWT use case, that seems like it would work out as he 
>> described it.  Note that he's primarily describing the protocol messages 
>> he's using to do the proof-of-possession - not just how to represent the PoP 
>> key in a JWT - which is the scope of this draft.  The PoP protocol pieces 
>> are explicitly out of scope for this draft - it's just about PoP key 
>> representation.
>> 
>> If I have the above right, does anyone believe that we nonetheless need to 
>> do an update to the draft?  If so, can you supply proposed wording or at 
>> least the gist of the additional ideas that you'd like to have conveyed.
>> 
>>        Best wishes,
>>    -- Mike
>> 
>> -Original Message-
>> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Kathleen Moriarty
>> Sent: Friday, November 20, 2015 11:12 AM
>> To: Chuck Mortimore 
>> Cc:  
>> Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec 
>> addressing final shepherd comment
>> 
>> Hi,
>> 
>> This draft was tossed over the fence to me, but it seems that there may be a 
>> few open questions that remain.  Use of HSM and TPMwere raised in this tread 
>> and not addressed in the current draft version.
>> 
>> Is guidance needed for nested JWTs?  If not, why?
>> 
>> In a separate thread, JWK is mentioned, but I'm okay with that text as there 
>> is a reference.
>> 
>> I'd like to get this moving, os if we can wrap up these questions and if 
>> anything will be done about them, it would be helpful.
>> 
>> Thank you,
>> Kathleen
>> 
>>> On Thu, Nov 5, 2015 at 3:07 PM, Chuck Mortimore  
>>> wrote:
>>> The spec is very clear for most cases, but I think it could use some
>>> guidance on nested JWTs.(Or perhaps I've got the approach wrong.)
>>> 
>>> Here's the use-case:
>>> We have devices that are self-issuing keys.Via token exchange, we're
>>> going to except a self-signed JWT from the device that includes a "cnf"
>>> claim of the key they generated.Assuming the signature checks out on
>>> that JWT, we'll then bind that key into a "cnf" claim in a new token 
>>> that we issue and sign with a tenant key.
>>> 
>>> When the device goes to use that token, the device would sign it, 
>>> constructing a nested JWT.  The outer signature is the proof of possession
>>> of the device's private key.   The inner 

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

[Brian Campbell]

Agree that the nested JWT question is really outside the scope of this
document. That's would be a way to try and actually prove the possession of
some key (though Chuck and I chatted offline about it some and are not
convinced it's a particularly good way) while this document is just about
how to indicate the key that will be proven somehow in a JWT. I do believe
there's a bit of a void on the PoP protocol side of things but that's a
different topic that shouldn't prevent this document from proceeding.

If I recall correctly, the HSM/TPM concerns were actually raised about
draft-ietf-oauth-pop-key-distribution-02 rather than this document.
Something about only wrapped secret keys being exportable from certain TPMs
or something like that. I'm not sure exactly what it was but don't think it
pertained to this document.



On Fri, Nov 20, 2015 at 12:32 PM, Mike Jones 
wrote:

> HSM-backed public keys would be represented in the same way that other
> public keys are - using the standard JWK representation for them.  Likewise
> for TPM-backed public keys.  That said, I'm not an expert in TPMs and know
> that they define TPM-specific signature formats but to my understanding,
> they're using standard kinds of keys.  If this isn't the case, a new key
> type ("kty") would be needed to represent them, but they'd still be
> represented as a JWK in the JWT using that key type.  The draft would still
> work fine for these use cases as written.  Does that sound right to people
> or am I missing something here?
>
> For Chuck's nested JWT use case, that seems like it would work out as he
> described it.  Note that he's primarily describing the protocol messages
> he's using to do the proof-of-possession - not just how to represent the
> PoP key in a JWT - which is the scope of this draft.  The PoP protocol
> pieces are explicitly out of scope for this draft - it's just about PoP key
> representation.
>
> If I have the above right, does anyone believe that we nonetheless need to
> do an update to the draft?  If so, can you supply proposed wording or at
> least the gist of the additional ideas that you'd like to have conveyed.
>
> Best wishes,
> -- Mike
>
> -Original Message-
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Kathleen Moriarty
> Sent: Friday, November 20, 2015 11:12 AM
> To: Chuck Mortimore 
> Cc:  
> Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec
> addressing final shepherd comment
>
> Hi,
>
> This draft was tossed over the fence to me, but it seems that there may be
> a few open questions that remain.  Use of HSM and TPMwere raised in this
> tread and not addressed in the current draft version.
>
> Is guidance needed for nested JWTs?  If not, why?
>
> In a separate thread, JWK is mentioned, but I'm okay with that text as
> there is a reference.
>
> I'd like to get this moving, os if we can wrap up these questions and if
> anything will be done about them, it would be helpful.
>
> Thank you,
> Kathleen
>
> On Thu, Nov 5, 2015 at 3:07 PM, Chuck Mortimore 
> wrote:
> > The spec is very clear for most cases, but I think it could use some
> > guidance on nested JWTs.(Or perhaps I've got the approach wrong.)
> >
> > Here's the use-case:
> > We have devices that are self-issuing keys.Via token exchange, we're
> > going to except a self-signed JWT from the device that includes a "cnf"
> > claim of the key they generated.Assuming the signature checks out on
> > that JWT, we'll then bind that key into a "cnf" claim in a new token
> > that we issue and sign with a tenant key.
> >
> > When the device goes to use that token, the device would sign it,
> > constructing a nested JWT.  The outer signature is the proof of
> possession
> > of the device's private key.   The inner signature is our signature that
> > binds the public key used to validate the outer token.
> >
> > Does this sound correct?   The processing order is a bit odd since you
> first
> > need to unpack and validate the inner token before you can validate the
> > outer token.   Is there some other way this is intended to work?
> >
> > thanks
> >
> > -cmort
> >
> >
> >
> > On Wed, Nov 4, 2015 at 8:58 PM, John Bradley  wrote:
> >>
> >> Good to know.   So the AS needs to expose a public key for the TPM to
> use
> >> for encryption.   I am guessing you are not using a encrypted JWK for
> that.
> >> What is the format the TPM produces the wrapped ke

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

[John Bradley]

I don’t know of any special requirements for representing HSM keys.   

How they are negotiated and stored is out of scope for this draft.

I think Brian mentioned that we had an example that is different from the 
default in the POP drafts.   That can be looked at.

I don’t think we want to get into key management.  That should be left to 
specifications that use this.

Chuck’s example gets into proof mechanisms for token presentment.
That is also out of scope for this draft.   There are two mechanisms as part of 
the POP specs.
One is mutual TLS and the other is using a signed message.  
I think the signed message one is what he is looking for.  
https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-01

I suppose that you could over sign the token itself but there are perhaps 
better ways to do it.
So if wrapping rules are needed that would probably be part of a pop token 
proof presentment spec.


John B.

> On Nov 20, 2015, at 4:32 PM, Mike Jones  wrote:
> 
> HSM-backed public keys would be represented in the same way that other public 
> keys are - using the standard JWK representation for them.  Likewise for 
> TPM-backed public keys.  That said, I'm not an expert in TPMs and know that 
> they define TPM-specific signature formats but to my understanding, they're 
> using standard kinds of keys.  If this isn't the case, a new key type ("kty") 
> would be needed to represent them, but they'd still be represented as a JWK 
> in the JWT using that key type.  The draft would still work fine for these 
> use cases as written.  Does that sound right to people or am I missing 
> something here?
> 
> For Chuck's nested JWT use case, that seems like it would work out as he 
> described it.  Note that he's primarily describing the protocol messages he's 
> using to do the proof-of-possession - not just how to represent the PoP key 
> in a JWT - which is the scope of this draft.  The PoP protocol pieces are 
> explicitly out of scope for this draft - it's just about PoP key 
> representation.
> 
> If I have the above right, does anyone believe that we nonetheless need to do 
> an update to the draft?  If so, can you supply proposed wording or at least 
> the gist of the additional ideas that you'd like to have conveyed.
> 
>   Best wishes,
>   -- Mike
> 
> -Original Message-
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Kathleen Moriarty
> Sent: Friday, November 20, 2015 11:12 AM
> To: Chuck Mortimore 
> Cc:  
> Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec 
> addressing final shepherd comment
> 
> Hi,
> 
> This draft was tossed over the fence to me, but it seems that there may be a 
> few open questions that remain.  Use of HSM and TPMwere raised in this tread 
> and not addressed in the current draft version.
> 
> Is guidance needed for nested JWTs?  If not, why?
> 
> In a separate thread, JWK is mentioned, but I'm okay with that text as there 
> is a reference.
> 
> I'd like to get this moving, os if we can wrap up these questions and if 
> anything will be done about them, it would be helpful.
> 
> Thank you,
> Kathleen
> 
> On Thu, Nov 5, 2015 at 3:07 PM, Chuck Mortimore  
> wrote:
>> The spec is very clear for most cases, but I think it could use some
>> guidance on nested JWTs.(Or perhaps I've got the approach wrong.)
>> 
>> Here's the use-case:
>> We have devices that are self-issuing keys.Via token exchange, we're
>> going to except a self-signed JWT from the device that includes a "cnf"
>> claim of the key they generated.Assuming the signature checks out on
>> that JWT, we'll then bind that key into a "cnf" claim in a new token 
>> that we issue and sign with a tenant key.
>> 
>> When the device goes to use that token, the device would sign it, 
>> constructing a nested JWT.  The outer signature is the proof of possession
>> of the device's private key.   The inner signature is our signature that
>> binds the public key used to validate the outer token.
>> 
>> Does this sound correct?   The processing order is a bit odd since you first
>> need to unpack and validate the inner token before you can validate the
>> outer token.   Is there some other way this is intended to work?
>> 
>> thanks
>> 
>> -cmort
>> 
>> 
>> 
>> On Wed, Nov 4, 2015 at 8:58 PM, John Bradley  wrote:
>>> 
>>> Good to know.   So the AS needs to expose a public key for the TPM to use
>>> for encryption.   I am guessing you are not using a encrypted JWK for that

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

[Mike Jones]

HSM-backed public keys would be represented in the same way that other public 
keys are - using the standard JWK representation for them.  Likewise for 
TPM-backed public keys.  That said, I'm not an expert in TPMs and know that 
they define TPM-specific signature formats but to my understanding, they're 
using standard kinds of keys.  If this isn't the case, a new key type ("kty") 
would be needed to represent them, but they'd still be represented as a JWK in 
the JWT using that key type.  The draft would still work fine for these use 
cases as written.  Does that sound right to people or am I missing something 
here?

For Chuck's nested JWT use case, that seems like it would work out as he 
described it.  Note that he's primarily describing the protocol messages he's 
using to do the proof-of-possession - not just how to represent the PoP key in 
a JWT - which is the scope of this draft.  The PoP protocol pieces are 
explicitly out of scope for this draft - it's just about PoP key representation.

If I have the above right, does anyone believe that we nonetheless need to do 
an update to the draft?  If so, can you supply proposed wording or at least the 
gist of the additional ideas that you'd like to have conveyed.

Best wishes,
-- Mike

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Kathleen Moriarty
Sent: Friday, November 20, 2015 11:12 AM
To: Chuck Mortimore 
Cc:  
Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec 
addressing final shepherd comment

Hi,

This draft was tossed over the fence to me, but it seems that there may be a 
few open questions that remain.  Use of HSM and TPMwere raised in this tread 
and not addressed in the current draft version.

Is guidance needed for nested JWTs?  If not, why?

In a separate thread, JWK is mentioned, but I'm okay with that text as there is 
a reference.

I'd like to get this moving, os if we can wrap up these questions and if 
anything will be done about them, it would be helpful.

Thank you,
Kathleen

On Thu, Nov 5, 2015 at 3:07 PM, Chuck Mortimore  
wrote:
> The spec is very clear for most cases, but I think it could use some
> guidance on nested JWTs.(Or perhaps I've got the approach wrong.)
>
> Here's the use-case:
> We have devices that are self-issuing keys.Via token exchange, we're
> going to except a self-signed JWT from the device that includes a "cnf"
> claim of the key they generated.Assuming the signature checks out on
> that JWT, we'll then bind that key into a "cnf" claim in a new token 
> that we issue and sign with a tenant key.
>
> When the device goes to use that token, the device would sign it, 
> constructing a nested JWT.  The outer signature is the proof of possession
> of the device's private key.   The inner signature is our signature that
> binds the public key used to validate the outer token.
>
> Does this sound correct?   The processing order is a bit odd since you first
> need to unpack and validate the inner token before you can validate the
> outer token.   Is there some other way this is intended to work?
>
> thanks
>
> -cmort
>
>
>
> On Wed, Nov 4, 2015 at 8:58 PM, John Bradley  wrote:
>>
>> Good to know.   So the AS needs to expose a public key for the TPM to use
>> for encryption.   I am guessing you are not using a encrypted JWK for that.
>> What is the format the TPM produces the wrapped key in?
>>
>> John B.
>> > On Nov 5, 2015, at 1:55 PM, Anthony Nadalin 
>> > wrote:
>> >
>> > I can say on all windows based devices (pc, xbox, phone, etc) with 
>> > only TPM 1.1 this will be the approach so it will be commonly used
>> >
>> > -Original Message-
>> > From: John Bradley [mailto:ve7...@ve7jtb.com]
>> > Sent: Wednesday, November 4, 2015 8:52 PM
>> > To: Anthony Nadalin 
>> > Cc: Justin Richer ;  
>> > 
>> > Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs 
>> > spec addressing final shepherd comment
>> >
>> > OK, no good reason unless the client is using a HSM that can do 
>> > HMAC and can export a symmetric key wrapped in a asymmetric key provided 
>> > by the AS.
>> >
>> > We don’t currently cover that use case of sending a wrapped 
>> > symmetric key to the AS in POP key distribution.
>> > I don’t know how common that is going to be, but it is worth 
>> > thinking about defining.
>> >
>> > John B.
>> >
>> >> On Nov 5, 2015, at 1:45 PM, Anthony Nadalin 
>> >> 
>> >> wrote:
&g

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

[Kathleen Moriarty]

Hi,

This draft was tossed over the fence to me, but it seems that there
may be a few open questions that remain.  Use of HSM and TPMwere
raised in this tread and not addressed in the current draft version.

Is guidance needed for nested JWTs?  If not, why?

In a separate thread, JWK is mentioned, but I'm okay with that text as
there is a reference.

I'd like to get this moving, os if we can wrap up these questions and
if anything will be done about them, it would be helpful.

Thank you,
Kathleen

On Thu, Nov 5, 2015 at 3:07 PM, Chuck Mortimore
 wrote:
> The spec is very clear for most cases, but I think it could use some
> guidance on nested JWTs.(Or perhaps I've got the approach wrong.)
>
> Here's the use-case:
> We have devices that are self-issuing keys.Via token exchange, we're
> going to except a self-signed JWT from the device that includes a "cnf"
> claim of the key they generated.Assuming the signature checks out on
> that JWT, we'll then bind that key into a "cnf" claim in a new token that we
> issue and sign with a tenant key.
>
> When the device goes to use that token, the device would sign it,
> constructing a nested JWT.  The outer signature is the proof of possession
> of the device's private key.   The inner signature is our signature that
> binds the public key used to validate the outer token.
>
> Does this sound correct?   The processing order is a bit odd since you first
> need to unpack and validate the inner token before you can validate the
> outer token.   Is there some other way this is intended to work?
>
> thanks
>
> -cmort
>
>
>
> On Wed, Nov 4, 2015 at 8:58 PM, John Bradley  wrote:
>>
>> Good to know.   So the AS needs to expose a public key for the TPM to use
>> for encryption.   I am guessing you are not using a encrypted JWK for that.
>> What is the format the TPM produces the wrapped key in?
>>
>> John B.
>> > On Nov 5, 2015, at 1:55 PM, Anthony Nadalin 
>> > wrote:
>> >
>> > I can say on all windows based devices (pc, xbox, phone, etc) with only
>> > TPM 1.1 this will be the approach so it will be commonly used
>> >
>> > -Original Message-
>> > From: John Bradley [mailto:ve7...@ve7jtb.com]
>> > Sent: Wednesday, November 4, 2015 8:52 PM
>> > To: Anthony Nadalin 
>> > Cc: Justin Richer ;  
>> > Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec
>> > addressing final shepherd comment
>> >
>> > OK, no good reason unless the client is using a HSM that can do HMAC and
>> > can export a symmetric key wrapped in a asymmetric key provided by the AS.
>> >
>> > We don’t currently cover that use case of sending a wrapped symmetric
>> > key to the AS in POP key distribution.
>> > I don’t know how common that is going to be, but it is worth thinking
>> > about defining.
>> >
>> > John B.
>> >
>> >> On Nov 5, 2015, at 1:45 PM, Anthony Nadalin 
>> >> wrote:
>> >>
>> >> Not sure why you think its weaker as it would be a wrapped key that
>> >> the hardware produces
>> >>
>> >> -Original Message-
>> >> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley
>> >> Sent: Wednesday, November 4, 2015 8:43 PM
>> >> To: Justin Richer 
>> >> Cc:  
>> >> Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs
>> >> spec addressing final shepherd comment
>> >>
>> >> In the asymmetric case the use of a HSM or secure element is the
>> >> argument for the client selecting the public key.   In those cases the
>> >> client is doing the key gen in hardware so one hopes it is OK.   In the
>> >> symetric case the client generating the key is weaker (as in I can’t think
>> >> of any really good reason).
>> >>
>> >>
>> >>> On Nov 5, 2015, at 1:35 PM, Justin Richer  wrote:
>> >>>
>> >>> I’d argue that it’s best practice, and in line with other parts of
>> >>> OAuth, if we assume the server generates it in the normal case (issuer ->
>> >>> presenter). Client generated token keys should be an exception, 
>> >>> especially
>> >>> in the asymmetric case.
>> >>>
>> >>> — Justin
>> >>>
>> >>>> On Nov 5, 2015, at 1:32 PM, John Bradley  wrote:
>> >>>>
>> >>>> Agreed the only real difference is the quality of the key. 

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

[Chuck Mortimore]

The spec is very clear for most cases, but I think it could use some
guidance on nested JWTs.(Or perhaps I've got the approach wrong.)

Here's the use-case:
We have devices that are self-issuing keys.Via token exchange, we're
going to except a self-signed JWT from the device that includes a "cnf"
claim of the key they generated.Assuming the signature checks out on
that JWT, we'll then bind that key into a "cnf" claim in a new token that
we issue and sign with a tenant key.

When the device goes to use that token, the device would sign it,
constructing a nested JWT.  The outer signature is the proof of possession
of the device's private key.   The inner signature is our signature that
binds the public key used to validate the outer token.

Does this sound correct?   The processing order is a bit odd since you
first need to unpack and validate the inner token before you can validate
the outer token.   Is there some other way this is intended to work?

thanks

-cmort



On Wed, Nov 4, 2015 at 8:58 PM, John Bradley  wrote:

> Good to know.   So the AS needs to expose a public key for the TPM to use
> for encryption.   I am guessing you are not using a encrypted JWK for
> that.  What is the format the TPM produces the wrapped key in?
>
> John B.
> > On Nov 5, 2015, at 1:55 PM, Anthony Nadalin 
> wrote:
> >
> > I can say on all windows based devices (pc, xbox, phone, etc) with only
> TPM 1.1 this will be the approach so it will be commonly used
> >
> > -Original Message-
> > From: John Bradley [mailto:ve7...@ve7jtb.com]
> > Sent: Wednesday, November 4, 2015 8:52 PM
> > To: Anthony Nadalin 
> > Cc: Justin Richer ;  
> > Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec
> addressing final shepherd comment
> >
> > OK, no good reason unless the client is using a HSM that can do HMAC and
> can export a symmetric key wrapped in a asymmetric key provided by the AS.
> >
> > We don’t currently cover that use case of sending a wrapped symmetric
> key to the AS in POP key distribution.
> > I don’t know how common that is going to be, but it is worth thinking
> about defining.
> >
> > John B.
> >
> >> On Nov 5, 2015, at 1:45 PM, Anthony Nadalin 
> wrote:
> >>
> >> Not sure why you think its weaker as it would be a wrapped key that
> >> the hardware produces
> >>
> >> -----Original Message-----
> >> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley
> >> Sent: Wednesday, November 4, 2015 8:43 PM
> >> To: Justin Richer 
> >> Cc:  
> >> Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs
> >> spec addressing final shepherd comment
> >>
> >> In the asymmetric case the use of a HSM or secure element is the
> argument for the client selecting the public key.   In those cases the
> client is doing the key gen in hardware so one hopes it is OK.   In the
> symetric case the client generating the key is weaker (as in I can’t think
> of any really good reason).
> >>
> >>
> >>> On Nov 5, 2015, at 1:35 PM, Justin Richer  wrote:
> >>>
> >>> I’d argue that it’s best practice, and in line with other parts of
> OAuth, if we assume the server generates it in the normal case (issuer ->
> presenter). Client generated token keys should be an exception, especially
> in the asymmetric case.
> >>>
> >>> — Justin
> >>>
> >>>> On Nov 5, 2015, at 1:32 PM, John Bradley  wrote:
> >>>>
> >>>> Agreed the only real difference is the quality of the key.  If the
> server generates it, then it knows that the client is not using the fixed
> hex value of DEADBEEF for everything.
> >>>>
> >>>> John B.
> >>>>> On Nov 5, 2015, at 9:25 AM, Hannes Tschofenig <
> hannes.tschofe...@gmx.net> wrote:
> >>>>>
> >>>>> I agree that the effect is the same. From a security point of view
> >>>>> there is only an impact if one of the two parties is in a better
> >>>>> position to generate random numbers, which is the basis for
> >>>>> generating a high entropy symmetric key.
> >>>>>
> >>>>> On 11/04/2015 11:51 PM, Mike Jones wrote:
> >>>>>> Thanks for the detailed read, Brian.  You’re right that in the
> >>>>>> symmetric case, either the issuer or the presenter can create the
> >>>>>> symmetric PoP key and share it with the other party, since the
> effect is equivale

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

[John Bradley]

Good to know.   So the AS needs to expose a public key for the TPM to use for 
encryption.   I am guessing you are not using a encrypted JWK for that.  What 
is the format the TPM produces the wrapped key in?

John B.
> On Nov 5, 2015, at 1:55 PM, Anthony Nadalin  wrote:
> 
> I can say on all windows based devices (pc, xbox, phone, etc) with only TPM 
> 1.1 this will be the approach so it will be commonly used 
> 
> -Original Message-
> From: John Bradley [mailto:ve7...@ve7jtb.com] 
> Sent: Wednesday, November 4, 2015 8:52 PM
> To: Anthony Nadalin 
> Cc: Justin Richer ;  
> Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec 
> addressing final shepherd comment
> 
> OK, no good reason unless the client is using a HSM that can do HMAC and can 
> export a symmetric key wrapped in a asymmetric key provided by the AS.
> 
> We don’t currently cover that use case of sending a wrapped symmetric key to 
> the AS in POP key distribution.   
> I don’t know how common that is going to be, but it is worth thinking about 
> defining.
> 
> John B.
> 
>> On Nov 5, 2015, at 1:45 PM, Anthony Nadalin  wrote:
>> 
>> Not sure why you think its weaker as it would be a wrapped key that 
>> the hardware produces
>> 
>> -Original Message-
>> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley
>> Sent: Wednesday, November 4, 2015 8:43 PM
>> To: Justin Richer 
>> Cc:  
>> Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs 
>> spec addressing final shepherd comment
>> 
>> In the asymmetric case the use of a HSM or secure element is the argument 
>> for the client selecting the public key.   In those cases the client is 
>> doing the key gen in hardware so one hopes it is OK.   In the symetric case 
>> the client generating the key is weaker (as in I can’t think of any really 
>> good reason).
>> 
>> 
>>> On Nov 5, 2015, at 1:35 PM, Justin Richer  wrote:
>>> 
>>> I’d argue that it’s best practice, and in line with other parts of OAuth, 
>>> if we assume the server generates it in the normal case (issuer -> 
>>> presenter). Client generated token keys should be an exception, especially 
>>> in the asymmetric case.
>>> 
>>> — Justin
>>> 
>>>> On Nov 5, 2015, at 1:32 PM, John Bradley  wrote:
>>>> 
>>>> Agreed the only real difference is the quality of the key.  If the server 
>>>> generates it, then it knows that the client is not using the fixed hex 
>>>> value of DEADBEEF for everything.
>>>> 
>>>> John B.
>>>>> On Nov 5, 2015, at 9:25 AM, Hannes Tschofenig  
>>>>> wrote:
>>>>> 
>>>>> I agree that the effect is the same. From a security point of view 
>>>>> there is only an impact if one of the two parties is in a better 
>>>>> position to generate random numbers, which is the basis for 
>>>>> generating a high entropy symmetric key.
>>>>> 
>>>>> On 11/04/2015 11:51 PM, Mike Jones wrote:
>>>>>> Thanks for the detailed read, Brian.  You’re right that in the 
>>>>>> symmetric case, either the issuer or the presenter can create the 
>>>>>> symmetric PoP key and share it with the other party, since the effect is 
>>>>>> equivalent.
>>>>>> I suspect that both the key distribution draft and this draft 
>>>>>> should be updated with a sentence or two saying that either 
>>>>>> approach can be taken.  Do others concur?
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>-- Mike
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> *From:*Brian Campbell [mailto:bcampb...@pingidentity.com]
>>>>>> *Sent:* Thursday, November 05, 2015 7:48 AM
>>>>>> *To:* Mike Jones
>>>>>> *Cc:* Kepeng Li; oauth@ietf.org
>>>>>> *Subject:* Re: [OAUTH-WG] Proof-of-Possession Key Semantics for 
>>>>>> JWTs spec addressing final shepherd comment
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> +1 for the diagrams making the document more understandable.
>>>>>> 
>>>>>> One little nit/question, step 1 in both Symmetric and Asymmetric 
>>>>>> keys shows the Presenter sending the key to the Issuer. It's 
>>>>>> possible, howe

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

[Anthony Nadalin]

I can say on all windows based devices (pc, xbox, phone, etc) with only TPM 1.1 
this will be the approach so it will be commonly used 

-Original Message-
From: John Bradley [mailto:ve7...@ve7jtb.com] 
Sent: Wednesday, November 4, 2015 8:52 PM
To: Anthony Nadalin 
Cc: Justin Richer ;  
Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec 
addressing final shepherd comment

OK, no good reason unless the client is using a HSM that can do HMAC and can 
export a symmetric key wrapped in a asymmetric key provided by the AS.

We don’t currently cover that use case of sending a wrapped symmetric key to 
the AS in POP key distribution.   
I don’t know how common that is going to be, but it is worth thinking about 
defining.

John B.

> On Nov 5, 2015, at 1:45 PM, Anthony Nadalin  wrote:
> 
> Not sure why you think its weaker as it would be a wrapped key that 
> the hardware produces
> 
> -Original Message-
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley
> Sent: Wednesday, November 4, 2015 8:43 PM
> To: Justin Richer 
> Cc:  
> Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs 
> spec addressing final shepherd comment
> 
> In the asymmetric case the use of a HSM or secure element is the argument for 
> the client selecting the public key.   In those cases the client is doing the 
> key gen in hardware so one hopes it is OK.   In the symetric case the client 
> generating the key is weaker (as in I can’t think of any really good reason).
> 
> 
>> On Nov 5, 2015, at 1:35 PM, Justin Richer  wrote:
>> 
>> I’d argue that it’s best practice, and in line with other parts of OAuth, if 
>> we assume the server generates it in the normal case (issuer -> presenter). 
>> Client generated token keys should be an exception, especially in the 
>> asymmetric case.
>> 
>> — Justin
>> 
>>> On Nov 5, 2015, at 1:32 PM, John Bradley  wrote:
>>> 
>>> Agreed the only real difference is the quality of the key.  If the server 
>>> generates it, then it knows that the client is not using the fixed hex 
>>> value of DEADBEEF for everything.
>>> 
>>> John B.
>>>> On Nov 5, 2015, at 9:25 AM, Hannes Tschofenig  
>>>> wrote:
>>>> 
>>>> I agree that the effect is the same. From a security point of view 
>>>> there is only an impact if one of the two parties is in a better 
>>>> position to generate random numbers, which is the basis for 
>>>> generating a high entropy symmetric key.
>>>> 
>>>> On 11/04/2015 11:51 PM, Mike Jones wrote:
>>>>> Thanks for the detailed read, Brian.  You’re right that in the 
>>>>> symmetric case, either the issuer or the presenter can create the 
>>>>> symmetric PoP key and share it with the other party, since the effect is 
>>>>> equivalent.
>>>>> I suspect that both the key distribution draft and this draft 
>>>>> should be updated with a sentence or two saying that either 
>>>>> approach can be taken.  Do others concur?
>>>>> 
>>>>> 
>>>>> 
>>>>> -- Mike
>>>>> 
>>>>> 
>>>>> 
>>>>> *From:*Brian Campbell [mailto:bcampb...@pingidentity.com]
>>>>> *Sent:* Thursday, November 05, 2015 7:48 AM
>>>>> *To:* Mike Jones
>>>>> *Cc:* Kepeng Li; oauth@ietf.org
>>>>> *Subject:* Re: [OAUTH-WG] Proof-of-Possession Key Semantics for 
>>>>> JWTs spec addressing final shepherd comment
>>>>> 
>>>>> 
>>>>> 
>>>>> +1 for the diagrams making the document more understandable.
>>>>> 
>>>>> One little nit/question, step 1 in both Symmetric and Asymmetric 
>>>>> keys shows the Presenter sending the key to the Issuer. It's 
>>>>> possible, however, for the key to be sent the other way. Presenter 
>>>>> sending it to the Issuer is probably preferred for asymmetric, 
>>>>> especially if the client can secure the private keys in hardware.
>>>>> But I don't know if one way or the other is clearly better for 
>>>>> symmetric case and PoP key distribution currently has it the other 
>>>>> way 
>>>>> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-oauth-pop-key-distribution-02%23section-4.2&data=01%7c01%7ctonynad%40microsoft.com%7c9456670075d04a51f85508d2e59ba294%7c

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

[Anthony Nadalin]

Our use case involves mostly hardware (TPM 1.2) based key generation, where the 
hardware (TPM 1.1) is slow we will use secure software execution environment, 
our use case is always client side generated keys

-Original Message-
From: Justin Richer [mailto:jric...@mit.edu] 
Sent: Wednesday, November 4, 2015 8:48 PM
To: Anthony Nadalin 
Cc: John Bradley ;  
Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec 
addressing final shepherd comment

That’s only if you’re using good hardware to produce a key. We can’t assume 
that’s the only kind of client that will exist, and software generation is 
likely to be much more common for a while yet.

Perhaps what we really need is strong guidance on when to use which approach. 
“If you client has a strong random generator function then you can make your 
own key, but otherwise let the server do it for you."

 — Justin

> On Nov 5, 2015, at 1:45 PM, Anthony Nadalin  wrote:
> 
> Not sure why you think its weaker as it would be a wrapped key that 
> the hardware produces
> 
> -Original Message-
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley
> Sent: Wednesday, November 4, 2015 8:43 PM
> To: Justin Richer 
> Cc:  
> Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs 
> spec addressing final shepherd comment
> 
> In the asymmetric case the use of a HSM or secure element is the argument for 
> the client selecting the public key.   In those cases the client is doing the 
> key gen in hardware so one hopes it is OK.   In the symetric case the client 
> generating the key is weaker (as in I can’t think of any really good reason).
> 
> 
>> On Nov 5, 2015, at 1:35 PM, Justin Richer  wrote:
>> 
>> I’d argue that it’s best practice, and in line with other parts of OAuth, if 
>> we assume the server generates it in the normal case (issuer -> presenter). 
>> Client generated token keys should be an exception, especially in the 
>> asymmetric case.
>> 
>> — Justin
>> 
>>> On Nov 5, 2015, at 1:32 PM, John Bradley  wrote:
>>> 
>>> Agreed the only real difference is the quality of the key.  If the server 
>>> generates it, then it knows that the client is not using the fixed hex 
>>> value of DEADBEEF for everything.
>>> 
>>> John B.
>>>> On Nov 5, 2015, at 9:25 AM, Hannes Tschofenig  
>>>> wrote:
>>>> 
>>>> I agree that the effect is the same. From a security point of view 
>>>> there is only an impact if one of the two parties is in a better 
>>>> position to generate random numbers, which is the basis for 
>>>> generating a high entropy symmetric key.
>>>> 
>>>> On 11/04/2015 11:51 PM, Mike Jones wrote:
>>>>> Thanks for the detailed read, Brian.  You’re right that in the 
>>>>> symmetric case, either the issuer or the presenter can create the 
>>>>> symmetric PoP key and share it with the other party, since the effect is 
>>>>> equivalent.
>>>>> I suspect that both the key distribution draft and this draft 
>>>>> should be updated with a sentence or two saying that either 
>>>>> approach can be taken.  Do others concur?
>>>>> 
>>>>> 
>>>>> 
>>>>> -- Mike
>>>>> 
>>>>> 
>>>>> 
>>>>> *From:*Brian Campbell [mailto:bcampb...@pingidentity.com]
>>>>> *Sent:* Thursday, November 05, 2015 7:48 AM
>>>>> *To:* Mike Jones
>>>>> *Cc:* Kepeng Li; oauth@ietf.org
>>>>> *Subject:* Re: [OAUTH-WG] Proof-of-Possession Key Semantics for 
>>>>> JWTs spec addressing final shepherd comment
>>>>> 
>>>>> 
>>>>> 
>>>>> +1 for the diagrams making the document more understandable.
>>>>> 
>>>>> One little nit/question, step 1 in both Symmetric and Asymmetric 
>>>>> keys shows the Presenter sending the key to the Issuer. It's 
>>>>> possible, however, for the key to be sent the other way. Presenter 
>>>>> sending it to the Issuer is probably preferred for asymmetric, 
>>>>> especially if the client can secure the private keys in hardware.
>>>>> But I don't know if one way or the other is clearly better for 
>>>>> symmetric case and PoP key distribution currently has it the other 
>>>>> way 
>>>>> <

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

[John Bradley]

OK, no good reason unless the client is using a HSM that can do HMAC and can 
export a symmetric key wrapped in a asymmetric key provided by the AS.

We don’t currently cover that use case of sending a wrapped symmetric key to 
the AS in POP key distribution.   
I don’t know how common that is going to be, but it is worth thinking about 
defining.

John B.

> On Nov 5, 2015, at 1:45 PM, Anthony Nadalin  wrote:
> 
> Not sure why you think its weaker as it would be a wrapped key that the 
> hardware produces 
> 
> -Original Message-
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley
> Sent: Wednesday, November 4, 2015 8:43 PM
> To: Justin Richer 
> Cc:  
> Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec 
> addressing final shepherd comment
> 
> In the asymmetric case the use of a HSM or secure element is the argument for 
> the client selecting the public key.   In those cases the client is doing the 
> key gen in hardware so one hopes it is OK.   In the symetric case the client 
> generating the key is weaker (as in I can’t think of any really good reason).
> 
> 
>> On Nov 5, 2015, at 1:35 PM, Justin Richer  wrote:
>> 
>> I’d argue that it’s best practice, and in line with other parts of OAuth, if 
>> we assume the server generates it in the normal case (issuer -> presenter). 
>> Client generated token keys should be an exception, especially in the 
>> asymmetric case.
>> 
>> — Justin
>> 
>>> On Nov 5, 2015, at 1:32 PM, John Bradley  wrote:
>>> 
>>> Agreed the only real difference is the quality of the key.  If the server 
>>> generates it, then it knows that the client is not using the fixed hex 
>>> value of DEADBEEF for everything.
>>> 
>>> John B.
>>>> On Nov 5, 2015, at 9:25 AM, Hannes Tschofenig  
>>>> wrote:
>>>> 
>>>> I agree that the effect is the same. From a security point of view 
>>>> there is only an impact if one of the two parties is in a better 
>>>> position to generate random numbers, which is the basis for 
>>>> generating a high entropy symmetric key.
>>>> 
>>>> On 11/04/2015 11:51 PM, Mike Jones wrote:
>>>>> Thanks for the detailed read, Brian.  You’re right that in the 
>>>>> symmetric case, either the issuer or the presenter can create the 
>>>>> symmetric PoP key and share it with the other party, since the effect is 
>>>>> equivalent.
>>>>> I suspect that both the key distribution draft and this draft 
>>>>> should be updated with a sentence or two saying that either 
>>>>> approach can be taken.  Do others concur?
>>>>> 
>>>>> 
>>>>> 
>>>>> -- Mike
>>>>> 
>>>>> 
>>>>> 
>>>>> *From:*Brian Campbell [mailto:bcampb...@pingidentity.com]
>>>>> *Sent:* Thursday, November 05, 2015 7:48 AM
>>>>> *To:* Mike Jones
>>>>> *Cc:* Kepeng Li; oauth@ietf.org
>>>>> *Subject:* Re: [OAUTH-WG] Proof-of-Possession Key Semantics for 
>>>>> JWTs spec addressing final shepherd comment
>>>>> 
>>>>> 
>>>>> 
>>>>> +1 for the diagrams making the document more understandable.
>>>>> 
>>>>> One little nit/question, step 1 in both Symmetric and Asymmetric 
>>>>> keys shows the Presenter sending the key to the Issuer. It's 
>>>>> possible, however, for the key to be sent the other way. Presenter 
>>>>> sending it to the Issuer is probably preferred for asymmetric, 
>>>>> especially if the client can secure the private keys in hardware. 
>>>>> But I don't know if one way or the other is clearly better for 
>>>>> symmetric case and PoP key distribution currently has it the other 
>>>>> way 
>>>>> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-oauth-pop-key-distribution-02%23section-4.2&data=01%7c01%7ctonynad%40microsoft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=UgZEoqQiaUk9VdYpSQRvUeVVOQgIUg3UmAr18oQ7GtI%3d>.
>>>>> Should the intro text somehow mention the possibility that the 
>>>>> Issuer could create the key and send it to the Presenter?
>>>>> 
>>>>> I know it's only the introduction but it was just something that 
>>&

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

[Justin Richer]

That’s only if you’re using good hardware to produce a key. We can’t assume 
that’s the only kind of client that will exist, and software generation is 
likely to be much more common for a while yet.

Perhaps what we really need is strong guidance on when to use which approach. 
“If you client has a strong random generator function then you can make your 
own key, but otherwise let the server do it for you."

 — Justin

> On Nov 5, 2015, at 1:45 PM, Anthony Nadalin  wrote:
> 
> Not sure why you think its weaker as it would be a wrapped key that the 
> hardware produces 
> 
> -Original Message-
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley
> Sent: Wednesday, November 4, 2015 8:43 PM
> To: Justin Richer 
> Cc:  
> Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec 
> addressing final shepherd comment
> 
> In the asymmetric case the use of a HSM or secure element is the argument for 
> the client selecting the public key.   In those cases the client is doing the 
> key gen in hardware so one hopes it is OK.   In the symetric case the client 
> generating the key is weaker (as in I can’t think of any really good reason).
> 
> 
>> On Nov 5, 2015, at 1:35 PM, Justin Richer  wrote:
>> 
>> I’d argue that it’s best practice, and in line with other parts of OAuth, if 
>> we assume the server generates it in the normal case (issuer -> presenter). 
>> Client generated token keys should be an exception, especially in the 
>> asymmetric case.
>> 
>> — Justin
>> 
>>> On Nov 5, 2015, at 1:32 PM, John Bradley  wrote:
>>> 
>>> Agreed the only real difference is the quality of the key.  If the server 
>>> generates it, then it knows that the client is not using the fixed hex 
>>> value of DEADBEEF for everything.
>>> 
>>> John B.
>>>> On Nov 5, 2015, at 9:25 AM, Hannes Tschofenig  
>>>> wrote:
>>>> 
>>>> I agree that the effect is the same. From a security point of view 
>>>> there is only an impact if one of the two parties is in a better 
>>>> position to generate random numbers, which is the basis for 
>>>> generating a high entropy symmetric key.
>>>> 
>>>> On 11/04/2015 11:51 PM, Mike Jones wrote:
>>>>> Thanks for the detailed read, Brian.  You’re right that in the 
>>>>> symmetric case, either the issuer or the presenter can create the 
>>>>> symmetric PoP key and share it with the other party, since the effect is 
>>>>> equivalent.
>>>>> I suspect that both the key distribution draft and this draft 
>>>>> should be updated with a sentence or two saying that either 
>>>>> approach can be taken.  Do others concur?
>>>>> 
>>>>> 
>>>>> 
>>>>> -- Mike
>>>>> 
>>>>> 
>>>>> 
>>>>> *From:*Brian Campbell [mailto:bcampb...@pingidentity.com]
>>>>> *Sent:* Thursday, November 05, 2015 7:48 AM
>>>>> *To:* Mike Jones
>>>>> *Cc:* Kepeng Li; oauth@ietf.org
>>>>> *Subject:* Re: [OAUTH-WG] Proof-of-Possession Key Semantics for 
>>>>> JWTs spec addressing final shepherd comment
>>>>> 
>>>>> 
>>>>> 
>>>>> +1 for the diagrams making the document more understandable.
>>>>> 
>>>>> One little nit/question, step 1 in both Symmetric and Asymmetric 
>>>>> keys shows the Presenter sending the key to the Issuer. It's 
>>>>> possible, however, for the key to be sent the other way. Presenter 
>>>>> sending it to the Issuer is probably preferred for asymmetric, 
>>>>> especially if the client can secure the private keys in hardware. 
>>>>> But I don't know if one way or the other is clearly better for 
>>>>> symmetric case and PoP key distribution currently has it the other 
>>>>> way 
>>>>> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-oauth-pop-key-distribution-02%23section-4.2&data=01%7c01%7ctonynad%40microsoft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=UgZEoqQiaUk9VdYpSQRvUeVVOQgIUg3UmAr18oQ7GtI%3d>.
>>>>> Should the intro text somehow mention the possibility that the 
>>>>> Issuer could create the key and send it to the Presenter?
>>>>> 
>>>>> I know it's only the in

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

[Anthony Nadalin]

Not sure why you think its weaker as it would be a wrapped key that the 
hardware produces 

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley
Sent: Wednesday, November 4, 2015 8:43 PM
To: Justin Richer 
Cc:  
Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec 
addressing final shepherd comment

In the asymmetric case the use of a HSM or secure element is the argument for 
the client selecting the public key.   In those cases the client is doing the 
key gen in hardware so one hopes it is OK.   In the symetric case the client 
generating the key is weaker (as in I can’t think of any really good reason).


> On Nov 5, 2015, at 1:35 PM, Justin Richer  wrote:
> 
> I’d argue that it’s best practice, and in line with other parts of OAuth, if 
> we assume the server generates it in the normal case (issuer -> presenter). 
> Client generated token keys should be an exception, especially in the 
> asymmetric case.
> 
> — Justin
> 
>> On Nov 5, 2015, at 1:32 PM, John Bradley  wrote:
>> 
>> Agreed the only real difference is the quality of the key.  If the server 
>> generates it, then it knows that the client is not using the fixed hex value 
>> of DEADBEEF for everything.
>> 
>> John B.
>>> On Nov 5, 2015, at 9:25 AM, Hannes Tschofenig  
>>> wrote:
>>> 
>>> I agree that the effect is the same. From a security point of view 
>>> there is only an impact if one of the two parties is in a better 
>>> position to generate random numbers, which is the basis for 
>>> generating a high entropy symmetric key.
>>> 
>>> On 11/04/2015 11:51 PM, Mike Jones wrote:
>>>> Thanks for the detailed read, Brian.  You’re right that in the 
>>>> symmetric case, either the issuer or the presenter can create the 
>>>> symmetric PoP key and share it with the other party, since the effect is 
>>>> equivalent.
>>>> I suspect that both the key distribution draft and this draft 
>>>> should be updated with a sentence or two saying that either 
>>>> approach can be taken.  Do others concur?
>>>> 
>>>> 
>>>> 
>>>>                          -- Mike
>>>> 
>>>> 
>>>> 
>>>> *From:*Brian Campbell [mailto:bcampb...@pingidentity.com]
>>>> *Sent:* Thursday, November 05, 2015 7:48 AM
>>>> *To:* Mike Jones
>>>> *Cc:* Kepeng Li; oauth@ietf.org
>>>> *Subject:* Re: [OAUTH-WG] Proof-of-Possession Key Semantics for 
>>>> JWTs spec addressing final shepherd comment
>>>> 
>>>> 
>>>> 
>>>> +1 for the diagrams making the document more understandable.
>>>> 
>>>> One little nit/question, step 1 in both Symmetric and Asymmetric 
>>>> keys shows the Presenter sending the key to the Issuer. It's 
>>>> possible, however, for the key to be sent the other way. Presenter 
>>>> sending it to the Issuer is probably preferred for asymmetric, 
>>>> especially if the client can secure the private keys in hardware. 
>>>> But I don't know if one way or the other is clearly better for 
>>>> symmetric case and PoP key distribution currently has it the other 
>>>> way 
>>>> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-oauth-pop-key-distribution-02%23section-4.2&data=01%7c01%7ctonynad%40microsoft.com%7c9456670075d04a51f85508d2e59ba294%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=UgZEoqQiaUk9VdYpSQRvUeVVOQgIUg3UmAr18oQ7GtI%3d>.
>>>> Should the intro text somehow mention the possibility that the 
>>>> Issuer could create the key and send it to the Presenter?
>>>> 
>>>> I know it's only the introduction but it was just something that 
>>>> jumped out at me.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On Wed, Nov 4, 2015 at 9:04 AM, Mike Jones 
>>>> mailto:michael.jo...@microsoft.com>> wrote:
>>>> 
>>>> Thanks for suggesting the diagrams, Kepeng. They make the document 
>>>> more understandable.
>>>> 
>>>> -- Mike
>>>> 
>>>> ---
>>>> -
>>>> 
>>>> *From: *Kepeng Li <mailto:kepeng@alibaba-inc.com>
>>>> *Sent: *‎11/‎5/‎2015 12:57 AM
>>>> *To: *Mike Jones <mailto:michael.jo...@microsoft.com>; 
>&

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

[John Bradley]

In the asymmetric case the use of a HSM or secure element is the argument for 
the client selecting the public key.   In those cases the client is doing the 
key gen in hardware so one hopes it is OK.   In the symetric case the client 
generating the key is weaker (as in I can’t think of any really good reason).


> On Nov 5, 2015, at 1:35 PM, Justin Richer  wrote:
> 
> I’d argue that it’s best practice, and in line with other parts of OAuth, if 
> we assume the server generates it in the normal case (issuer -> presenter). 
> Client generated token keys should be an exception, especially in the 
> asymmetric case.
> 
> — Justin
> 
>> On Nov 5, 2015, at 1:32 PM, John Bradley  wrote:
>> 
>> Agreed the only real difference is the quality of the key.  If the server 
>> generates it, then it knows that the client is not using the fixed hex value 
>> of DEADBEEF for everything.
>> 
>> John B.
>>> On Nov 5, 2015, at 9:25 AM, Hannes Tschofenig  
>>> wrote:
>>> 
>>> I agree that the effect is the same. From a security point of view there
>>> is only an impact if one of the two parties is in a better position to
>>> generate random numbers, which is the basis for generating a high
>>> entropy symmetric key.
>>> 
>>> On 11/04/2015 11:51 PM, Mike Jones wrote:
>>>> Thanks for the detailed read, Brian.  You’re right that in the symmetric
>>>> case, either the issuer or the presenter can create the symmetric PoP
>>>> key and share it with the other party, since the effect is equivalent. 
>>>> I suspect that both the key distribution draft and this draft should be
>>>> updated with a sentence or two saying that either approach can be
>>>> taken.  Do others concur?
>>>> 
>>>> 
>>>> 
>>>>                              -- Mike
>>>> 
>>>> 
>>>> 
>>>> *From:*Brian Campbell [mailto:bcampb...@pingidentity.com]
>>>> *Sent:* Thursday, November 05, 2015 7:48 AM
>>>> *To:* Mike Jones
>>>> *Cc:* Kepeng Li; oauth@ietf.org
>>>> *Subject:* Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs
>>>> spec addressing final shepherd comment
>>>> 
>>>> 
>>>> 
>>>> +1 for the diagrams making the document more understandable.
>>>> 
>>>> One little nit/question, step 1 in both Symmetric and Asymmetric keys
>>>> shows the Presenter sending the key to the Issuer. It's possible,
>>>> however, for the key to be sent the other way. Presenter sending it to
>>>> the Issuer is probably preferred for asymmetric, especially if the
>>>> client can secure the private keys in hardware. But I don't know if one
>>>> way or the other is clearly better for symmetric case and PoP key
>>>> distribution currently has it the other way
>>>> <https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-02#section-4.2>.
>>>> Should the intro text somehow mention the possibility that the Issuer
>>>> could create the key and send it to the Presenter?
>>>> 
>>>> I know it's only the introduction but it was just something that jumped
>>>> out at me.  
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On Wed, Nov 4, 2015 at 9:04 AM, Mike Jones >>> <mailto:michael.jo...@microsoft.com>> wrote:
>>>> 
>>>> Thanks for suggesting the diagrams, Kepeng. They make the document more
>>>> understandable.
>>>> 
>>>> -- Mike
>>>> 
>>>> 
>>>> 
>>>> *From: *Kepeng Li <mailto:kepeng@alibaba-inc.com>
>>>> *Sent: *‎11/‎5/‎2015 12:57 AM
>>>> *To: *Mike Jones <mailto:michael.jo...@microsoft.com>; oauth@ietf.org
>>>> <mailto:oauth@ietf.org>
>>>> *Subject: *Re: Proof-of-Possession Key Semantics for JWTs spec
>>>> addressing final shepherd comment
>>>> 
>>>> Thank you Mike.
>>>> 
>>>> 
>>>> 
>>>> The diagrams look good to me.
>>>> 
>>>> 
>>>> 
>>>> Kind Regards
>>>> 
>>>> Kepeng
>>>> 
>>>> 
>>>> 
>>>> *发件人**: *Mike Jones >>> <mailto:michael.jo...@microsoft.com>>
>>>> *日期**: *Thursday, 5 Novemb

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

[Justin Richer]

I’d argue that it’s best practice, and in line with other parts of OAuth, if we 
assume the server generates it in the normal case (issuer -> presenter). Client 
generated token keys should be an exception, especially in the asymmetric case.

 — Justin

> On Nov 5, 2015, at 1:32 PM, John Bradley  wrote:
> 
> Agreed the only real difference is the quality of the key.  If the server 
> generates it, then it knows that the client is not using the fixed hex value 
> of DEADBEEF for everything.
> 
> John B.
>> On Nov 5, 2015, at 9:25 AM, Hannes Tschofenig  
>> wrote:
>> 
>> I agree that the effect is the same. From a security point of view there
>> is only an impact if one of the two parties is in a better position to
>> generate random numbers, which is the basis for generating a high
>> entropy symmetric key.
>> 
>> On 11/04/2015 11:51 PM, Mike Jones wrote:
>>> Thanks for the detailed read, Brian.  You’re right that in the symmetric
>>> case, either the issuer or the presenter can create the symmetric PoP
>>> key and share it with the other party, since the effect is equivalent. 
>>> I suspect that both the key distribution draft and this draft should be
>>> updated with a sentence or two saying that either approach can be
>>> taken.  Do others concur?
>>> 
>>> 
>>> 
>>>   -- Mike
>>> 
>>> 
>>> 
>>> *From:*Brian Campbell [mailto:bcampb...@pingidentity.com]
>>> *Sent:* Thursday, November 05, 2015 7:48 AM
>>> *To:* Mike Jones
>>> *Cc:* Kepeng Li; oauth@ietf.org
>>> *Subject:* Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs
>>> spec addressing final shepherd comment
>>> 
>>> 
>>> 
>>> +1 for the diagrams making the document more understandable.
>>> 
>>> One little nit/question, step 1 in both Symmetric and Asymmetric keys
>>> shows the Presenter sending the key to the Issuer. It's possible,
>>> however, for the key to be sent the other way. Presenter sending it to
>>> the Issuer is probably preferred for asymmetric, especially if the
>>> client can secure the private keys in hardware. But I don't know if one
>>> way or the other is clearly better for symmetric case and PoP key
>>> distribution currently has it the other way
>>> <https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-02#section-4.2>.
>>> Should the intro text somehow mention the possibility that the Issuer
>>> could create the key and send it to the Presenter?
>>> 
>>> I know it's only the introduction but it was just something that jumped
>>> out at me.  
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On Wed, Nov 4, 2015 at 9:04 AM, Mike Jones >> <mailto:michael.jo...@microsoft.com>> wrote:
>>> 
>>> Thanks for suggesting the diagrams, Kepeng. They make the document more
>>> understandable.
>>> 
>>> -- Mike
>>> 
>>> 
>>> 
>>> *From: *Kepeng Li <mailto:kepeng@alibaba-inc.com>
>>> *Sent: *‎11/‎5/‎2015 12:57 AM
>>> *To: *Mike Jones <mailto:michael.jo...@microsoft.com>; oauth@ietf.org
>>> <mailto:oauth@ietf.org>
>>> *Subject: *Re: Proof-of-Possession Key Semantics for JWTs spec
>>> addressing final shepherd comment
>>> 
>>> Thank you Mike.
>>> 
>>> 
>>> 
>>> The diagrams look good to me.
>>> 
>>> 
>>> 
>>> Kind Regards
>>> 
>>> Kepeng
>>> 
>>> 
>>> 
>>> *发件人**: *Mike Jones >> <mailto:michael.jo...@microsoft.com>>
>>> *日期**: *Thursday, 5 November, 2015 12:32 am
>>> *至**: *"oauth@ietf.org <mailto:oauth@ietf.org>" >> <mailto:oauth@ietf.org>>
>>> *抄送**: *Li Kepeng >> <mailto:kepeng@alibaba-inc.com>>
>>> *主题**: *Proof-of-Possession Key Semantics for JWTs spec addressing
>>> final shepherd comment
>>> 
>>> 
>>> 
>>> Proof-of-Possession Key Semantics for JWTs draft -06 addresses the
>>> remaining document shepherd comment – adding use case diagrams to the
>>> introduction.
>>> 
>>> 
>>> 
>>> The updated specification is available at:
>>> 
>>> ·http://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-06
>>> 
&

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

[John Bradley]

Agreed the only real difference is the quality of the key.  If the server 
generates it, then it knows that the client is not using the fixed hex value of 
DEADBEEF for everything.

John B.
> On Nov 5, 2015, at 9:25 AM, Hannes Tschofenig  
> wrote:
> 
> I agree that the effect is the same. From a security point of view there
> is only an impact if one of the two parties is in a better position to
> generate random numbers, which is the basis for generating a high
> entropy symmetric key.
> 
> On 11/04/2015 11:51 PM, Mike Jones wrote:
>> Thanks for the detailed read, Brian.  You’re right that in the symmetric
>> case, either the issuer or the presenter can create the symmetric PoP
>> key and share it with the other party, since the effect is equivalent. 
>> I suspect that both the key distribution draft and this draft should be
>> updated with a sentence or two saying that either approach can be
>> taken.  Do others concur?
>> 
>> 
>> 
>>-- Mike
>> 
>> 
>> 
>> *From:*Brian Campbell [mailto:bcampb...@pingidentity.com]
>> *Sent:* Thursday, November 05, 2015 7:48 AM
>> *To:* Mike Jones
>> *Cc:* Kepeng Li; oauth@ietf.org
>> *Subject:* Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs
>> spec addressing final shepherd comment
>> 
>> 
>> 
>> +1 for the diagrams making the document more understandable.
>> 
>> One little nit/question, step 1 in both Symmetric and Asymmetric keys
>> shows the Presenter sending the key to the Issuer. It's possible,
>> however, for the key to be sent the other way. Presenter sending it to
>> the Issuer is probably preferred for asymmetric, especially if the
>> client can secure the private keys in hardware. But I don't know if one
>> way or the other is clearly better for symmetric case and PoP key
>> distribution currently has it the other way
>> <https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-02#section-4.2>.
>> Should the intro text somehow mention the possibility that the Issuer
>> could create the key and send it to the Presenter?
>> 
>> I know it's only the introduction but it was just something that jumped
>> out at me.  
>> 
>> 
>> 
>> 
>> 
>> On Wed, Nov 4, 2015 at 9:04 AM, Mike Jones > <mailto:michael.jo...@microsoft.com>> wrote:
>> 
>> Thanks for suggesting the diagrams, Kepeng. They make the document more
>> understandable.
>> 
>> -- Mike
>> 
>> 
>> 
>> *From: *Kepeng Li <mailto:kepeng@alibaba-inc.com>
>> *Sent: *‎11/‎5/‎2015 12:57 AM
>> *To: *Mike Jones <mailto:michael.jo...@microsoft.com>; oauth@ietf.org
>> <mailto:oauth@ietf.org>
>> *Subject: *Re: Proof-of-Possession Key Semantics for JWTs spec
>> addressing final shepherd comment
>> 
>> Thank you Mike.
>> 
>> 
>> 
>> The diagrams look good to me.
>> 
>> 
>> 
>> Kind Regards
>> 
>> Kepeng
>> 
>> 
>> 
>> *发件人**: *Mike Jones > <mailto:michael.jo...@microsoft.com>>
>> *日期**: *Thursday, 5 November, 2015 12:32 am
>> *至**: *"oauth@ietf.org <mailto:oauth@ietf.org>" > <mailto:oauth@ietf.org>>
>> *抄送**: *Li Kepeng > <mailto:kepeng@alibaba-inc.com>>
>> *主题**: *Proof-of-Possession Key Semantics for JWTs spec addressing
>> final shepherd comment
>> 
>> 
>> 
>> Proof-of-Possession Key Semantics for JWTs draft -06 addresses the
>> remaining document shepherd comment – adding use case diagrams to the
>> introduction.
>> 
>> 
>> 
>> The updated specification is available at:
>> 
>> ·http://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-06
>> 
>> 
>> 
>> An HTML formatted version is also available at:
>> 
>> ·   
>> https://self-issued.info/docs/draft-ietf-oauth-proof-of-possession-06.html
>> 
>> 
>> 
>>-- Mike
>> 
>> 
>> 
>> P.S.  This note was also posted at http://self-issued.info/?p=1471 and
>> as @selfissued <https://twitter.com/selfissued>.
>> 
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> 
>> 
>> 
>> 
>> ___
>> 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

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

[Mike Jones]

Good point.  I'll republish in the next day or so adding that to the security 
considerations.

-- Mike

-Original Message-
From: Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net] 
Sent: Thursday, November 05, 2015 9:26 AM
To: Mike Jones; Brian Campbell
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec 
addressing final shepherd comment

I agree that the effect is the same. From a security point of view there is 
only an impact if one of the two parties is in a better position to generate 
random numbers, which is the basis for generating a high entropy symmetric key.

On 11/04/2015 11:51 PM, Mike Jones wrote:
> Thanks for the detailed read, Brian.  You’re right that in the 
> symmetric case, either the issuer or the presenter can create the 
> symmetric PoP key and share it with the other party, since the effect is 
> equivalent.
> I suspect that both the key distribution draft and this draft should 
> be updated with a sentence or two saying that either approach can be 
> taken.  Do others concur?
> 
>  
> 
> -- Mike
> 
>  
> 
> *From:*Brian Campbell [mailto:bcampb...@pingidentity.com]
> *Sent:* Thursday, November 05, 2015 7:48 AM
> *To:* Mike Jones
> *Cc:* Kepeng Li; oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs 
> spec addressing final shepherd comment
> 
>  
> 
> +1 for the diagrams making the document more understandable.
> 
> One little nit/question, step 1 in both Symmetric and Asymmetric keys 
> shows the Presenter sending the key to the Issuer. It's possible, 
> however, for the key to be sent the other way. Presenter sending it to 
> the Issuer is probably preferred for asymmetric, especially if the 
> client can secure the private keys in hardware. But I don't know if 
> one way or the other is clearly better for symmetric case and PoP key 
> distribution currently has it the other way 
> <https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-02#section-4.2>.
> Should the intro text somehow mention the possibility that the Issuer 
> could create the key and send it to the Presenter?
> 
> I know it's only the introduction but it was just something that 
> jumped out at me.
> 
>  
> 
>  
> 
> On Wed, Nov 4, 2015 at 9:04 AM, Mike Jones 
> mailto:michael.jo...@microsoft.com>> wrote:
> 
> Thanks for suggesting the diagrams, Kepeng. They make the document 
> more understandable.
> 
> -- Mike
> 
> --
> --
> 
> *From: *Kepeng Li <mailto:kepeng@alibaba-inc.com>
> *Sent: *‎11/‎5/‎2015 12:57 AM
> *To: *Mike Jones <mailto:michael.jo...@microsoft.com>; oauth@ietf.org 
> <mailto:oauth@ietf.org>
> *Subject: *Re: Proof-of-Possession Key Semantics for JWTs spec 
> addressing final shepherd comment
> 
> Thank you Mike.
> 
>  
> 
> The diagrams look good to me.
> 
>  
> 
> Kind Regards
> 
> Kepeng
> 
>  
> 
> *发件人**: *Mike Jones  <mailto:michael.jo...@microsoft.com>>
> *日期**: *Thursday, 5 November, 2015 12:32 am
> *至**: *"oauth@ietf.org <mailto:oauth@ietf.org>"  <mailto:oauth@ietf.org>>
> *抄送**: *Li Kepeng  <mailto:kepeng@alibaba-inc.com>>
> *主题**: *Proof-of-Possession Key Semantics for JWTs spec addressing 
> final shepherd comment
> 
>  
> 
> Proof-of-Possession Key Semantics for JWTs draft -06 addresses the 
> remaining document shepherd comment – adding use case diagrams to the 
> introduction.
> 
>  
> 
> The updated specification is available at:
> 
> ·http://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-06
> 
>  
> 
> An HTML formatted version is also available at:
> 
> ·   
> https://self-issued.info/docs/draft-ietf-oauth-proof-of-possession-06.
> html
> 
>  
> 
> -- Mike
> 
>  
> 
> P.S.  This note was also posted at http://self-issued.info/?p=1471 and 
> as @selfissued <https://twitter.com/selfissued>.
> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org <mailto:OAuth@ietf.org> 
> https://www.ietf.org/mailman/listinfo/oauth
> 
>  
> 
> 
> 
> ___
> 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

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

[Hannes Tschofenig]

I agree that the effect is the same. From a security point of view there
is only an impact if one of the two parties is in a better position to
generate random numbers, which is the basis for generating a high
entropy symmetric key.

On 11/04/2015 11:51 PM, Mike Jones wrote:
> Thanks for the detailed read, Brian.  You’re right that in the symmetric
> case, either the issuer or the presenter can create the symmetric PoP
> key and share it with the other party, since the effect is equivalent. 
> I suspect that both the key distribution draft and this draft should be
> updated with a sentence or two saying that either approach can be
> taken.  Do others concur?
> 
>  
> 
> -- Mike
> 
>  
> 
> *From:*Brian Campbell [mailto:bcampb...@pingidentity.com]
> *Sent:* Thursday, November 05, 2015 7:48 AM
> *To:* Mike Jones
> *Cc:* Kepeng Li; oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs
> spec addressing final shepherd comment
> 
>  
> 
> +1 for the diagrams making the document more understandable.
> 
> One little nit/question, step 1 in both Symmetric and Asymmetric keys
> shows the Presenter sending the key to the Issuer. It's possible,
> however, for the key to be sent the other way. Presenter sending it to
> the Issuer is probably preferred for asymmetric, especially if the
> client can secure the private keys in hardware. But I don't know if one
> way or the other is clearly better for symmetric case and PoP key
> distribution currently has it the other way
> <https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-02#section-4.2>.
> Should the intro text somehow mention the possibility that the Issuer
> could create the key and send it to the Presenter?
> 
> I know it's only the introduction but it was just something that jumped
> out at me.  
> 
>  
> 
>  
> 
> On Wed, Nov 4, 2015 at 9:04 AM, Mike Jones  <mailto:michael.jo...@microsoft.com>> wrote:
> 
> Thanks for suggesting the diagrams, Kepeng. They make the document more
> understandable.
> 
> -- Mike
> 
> 
> 
> *From: *Kepeng Li <mailto:kepeng@alibaba-inc.com>
> *Sent: *‎11/‎5/‎2015 12:57 AM
> *To: *Mike Jones <mailto:michael.jo...@microsoft.com>; oauth@ietf.org
> <mailto:oauth@ietf.org>
> *Subject: *Re: Proof-of-Possession Key Semantics for JWTs spec
> addressing final shepherd comment
> 
> Thank you Mike.
> 
>  
> 
> The diagrams look good to me.
> 
>  
> 
> Kind Regards
> 
> Kepeng
> 
>  
> 
> *发件人**: *Mike Jones  <mailto:michael.jo...@microsoft.com>>
> *日期**: *Thursday, 5 November, 2015 12:32 am
> *至**: *"oauth@ietf.org <mailto:oauth@ietf.org>"  <mailto:oauth@ietf.org>>
> *抄送**: *Li Kepeng  <mailto:kepeng@alibaba-inc.com>>
> *主题**: *Proof-of-Possession Key Semantics for JWTs spec addressing
> final shepherd comment
> 
>  
> 
> Proof-of-Possession Key Semantics for JWTs draft -06 addresses the
> remaining document shepherd comment – adding use case diagrams to the
> introduction.
> 
>  
> 
> The updated specification is available at:
> 
> ·http://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-06
> 
>  
> 
> An HTML formatted version is also available at:
> 
> ·   
> https://self-issued.info/docs/draft-ietf-oauth-proof-of-possession-06.html
> 
>  
> 
> -- Mike
> 
>  
> 
> P.S.  This note was also posted at http://self-issued.info/?p=1471 and
> as @selfissued <https://twitter.com/selfissued>.
> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth
> 
>  
> 
> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> 



signature.asc
Description: OpenPGP digital signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

[Mike Jones]

Thanks for the detailed read, Brian.  You’re right that in the symmetric case, 
either the issuer or the presenter can create the symmetric PoP key and share 
it with the other party, since the effect is equivalent.  I suspect that both 
the key distribution draft and this draft should be updated with a sentence or 
two saying that either approach can be taken.  Do others concur?

-- Mike

From: Brian Campbell [mailto:bcampb...@pingidentity.com]
Sent: Thursday, November 05, 2015 7:48 AM
To: Mike Jones
Cc: Kepeng Li; oauth@ietf.org
Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec 
addressing final shepherd comment

+1 for the diagrams making the document more understandable.
One little nit/question, step 1 in both Symmetric and Asymmetric keys shows the 
Presenter sending the key to the Issuer. It's possible, however, for the key to 
be sent the other way. Presenter sending it to the Issuer is probably preferred 
for asymmetric, especially if the client can secure the private keys in 
hardware. But I don't know if one way or the other is clearly better for 
symmetric case and PoP key distribution currently has it the other 
way<https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-02#section-4.2>.
 Should the intro text somehow mention the possibility that the Issuer could 
create the key and send it to the Presenter?
I know it's only the introduction but it was just something that jumped out at 
me.


On Wed, Nov 4, 2015 at 9:04 AM, Mike Jones 
mailto:michael.jo...@microsoft.com>> wrote:
Thanks for suggesting the diagrams, Kepeng. They make the document more 
understandable.

-- Mike

From: Kepeng Li<mailto:kepeng@alibaba-inc.com>
Sent: ‎11/‎5/‎2015 12:57 AM
To: Mike Jones<mailto:michael.jo...@microsoft.com>; 
oauth@ietf.org<mailto:oauth@ietf.org>
Subject: Re: Proof-of-Possession Key Semantics for JWTs spec addressing final 
shepherd comment
Thank you Mike.

The diagrams look good to me.

Kind Regards
Kepeng

发件人: Mike Jones 
mailto:michael.jo...@microsoft.com>>
日期: Thursday, 5 November, 2015 12:32 am
至: "oauth@ietf.org<mailto:oauth@ietf.org>" 
mailto:oauth@ietf.org>>
抄送: Li Kepeng mailto:kepeng@alibaba-inc.com>>
主题: Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd 
comment

Proof-of-Possession Key Semantics for JWTs draft -06 addresses the remaining 
document shepherd comment – adding use case diagrams to the introduction.

The updated specification is available at:

·http://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-06

An HTML formatted version is also available at:

·
https://self-issued.info/docs/draft-ietf-oauth-proof-of-possession-06.html

-- Mike

P.S.  This note was also posted at http://self-issued.info/?p=1471 and as 
@selfissued<https://twitter.com/selfissued>.

___
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

[Brian Campbell]

+1 for the diagrams making the document more understandable.

One little nit/question, step 1 in both Symmetric and Asymmetric keys shows
the Presenter sending the key to the Issuer. It's possible, however, for
the key to be sent the other way. Presenter sending it to the Issuer is
probably preferred for asymmetric, especially if the client can secure the
private keys in hardware. But I don't know if one way or the other is
clearly better for symmetric case and PoP key distribution currently has it
the other way
.
Should the intro text somehow mention the possibility that the Issuer could
create the key and send it to the Presenter?

I know it's only the introduction but it was just something that jumped out
at me.



On Wed, Nov 4, 2015 at 9:04 AM, Mike Jones 
wrote:

> Thanks for suggesting the diagrams, Kepeng. They make the document more
> understandable.
>
> -- Mike
> --
> From: Kepeng Li 
> Sent: ‎11/‎5/‎2015 12:57 AM
> To: Mike Jones ; oauth@ietf.org
> Subject: Re: Proof-of-Possession Key Semantics for JWTs spec addressing
> final shepherd comment
>
> Thank you Mike.
>
> The diagrams look good to me.
>
> Kind Regards
> Kepeng
>
> 发件人: Mike Jones 
> 日期: Thursday, 5 November, 2015 12:32 am
> 至: "oauth@ietf.org" 
> 抄送: Li Kepeng 
> 主题: Proof-of-Possession Key Semantics for JWTs spec addressing final
> shepherd comment
>
> Proof-of-Possession Key Semantics for JWTs draft -06 addresses the
> remaining document shepherd comment – adding use case diagrams to the
> introduction.
>
>
>
> The updated specification is available at:
>
> ·
> http://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-06
>
>
>
> An HTML formatted version is also available at:
>
> ·
> https://self-issued.info/docs/draft-ietf-oauth-proof-of-possession-06.html
>
>
>
> -- Mike
>
>
>
> P.S.  This note was also posted at http://self-issued.info/?p=1471 and as
> @selfissued .
>
> ___
> 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

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

[Kepeng Li]

Thank you Mike.

The diagrams look good to me.

Kind Regards
Kepeng

发件人:  Mike Jones 
日期:  Thursday, 5 November, 2015 12:32 am
至:  "oauth@ietf.org" 
抄送:  Li Kepeng 
主题:  Proof-of-Possession Key Semantics for JWTs spec addressing final
shepherd comment

Proof-of-Possession Key Semantics for JWTs draft -06 addresses the remaining
document shepherd comment – adding use case diagrams to the introduction.
 
The updated specification is available at:
·   http://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-06

 
An HTML formatted version is also available at:
·   
https://self-issued.info/docs/draft-ietf-oauth-proof-of-possession-06.html

 
-- Mike
 
P.S.  This note was also posted at http://self-issued.info/?p=1471 and as
@selfissued  .


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

[Mike Jones]

Thanks for suggesting the diagrams, Kepeng. They make the document more 
understandable.

-- Mike

From: Kepeng Li
Sent: ‎11/‎5/‎2015 12:57 AM
To: Mike Jones; 
oauth@ietf.org
Subject: Re: Proof-of-Possession Key Semantics for JWTs spec addressing final 
shepherd comment

Thank you Mike.

The diagrams look good to me.

Kind Regards
Kepeng

???: Mike Jones 
mailto:michael.jo...@microsoft.com>>
??: Thursday, 5 November, 2015 12:32 am
?: "oauth@ietf.org" 
mailto:oauth@ietf.org>>
??: Li Kepeng mailto:kepeng@alibaba-inc.com>>
??: Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd 
comment

Proof-of-Possession Key Semantics for JWTs draft -06 addresses the remaining 
document shepherd comment – adding use case diagrams to the introduction.

The updated specification is available at:

·http://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-06

An HTML formatted version is also available at:

·
https://self-issued.info/docs/draft-ietf-oauth-proof-of-possession-06.html

-- Mike

P.S.  This note was also posted at http://self-issued.info/?p=1471 and as 
@selfissued.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

[Mike Jones]

Proof-of-Possession Key Semantics for JWTs draft -06 addresses the remaining 
document shepherd comment - adding use case diagrams to the introduction.

The updated specification is available at:

*http://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-06

An HTML formatted version is also available at:

*
https://self-issued.info/docs/draft-ietf-oauth-proof-of-possession-06.html

-- Mike

P.S.  This note was also posted at http://self-issued.info/?p=1471 and as 
@selfissued.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth