[OAUTH-WG] I-D Action: draft-ietf-oauth-pop-key-distribution-03.txt

[i***@ietf.org]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol of the IETF.

Title : OAuth 2.0 Proof-of-Possession: Authorization Server to Client Key Distribution
Authors : John Bradley
Phil Hunt
Michael B. Jones
Hannes Tschofenig
Filename : draft-ietf-oauth-pop-key-distribution-03.txt
Pages : 18
Date : 2017-02-24

Abstract:
RFC 6750 specified the bearer token concept for securing access to
protected resources. Bearer tokens need to be protected in transit
as well as at rest. When a client requests access to a protected
resource it hands-over the bearer token to the resource server.

The OAuth 2.0 Proof-of-Possession security concept extends bearer
token security and requires the client to demonstrate possession of a
key when accessing a protected resource.

This document describes how the client obtains this keying material
from the authorization server.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-key-distribution/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-pop-key-distribution-03


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

[John Bradley]

I updated the references but haven't made any other changes.

I had some questions about it so though it was worth keeping alive at-least for discussion.

There have been some other questions and proposed changes.

I will take a look through them and see if what may be worth updating.

John B.

Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-key-distribution-03.txt
Date: February 24, 2017 at 6:55:25 PM GMT-3
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol of the IETF.
Title : OAuth 2.0 Proof-of-Possession: Authorization Server to Client Key Distribution
Authors : John Bradley
Phil Hunt
Michael B. Jones
Hannes Tschofenig
Filename : draft-ietf-oauth-pop-key-distribution-03.txt
Pages : 18
Date : 2017-02-24
RFC 6750 specified the bearer token concept for securing access to
protected resources. Bearer tokens need to be protected in transit
as well as at rest. When a client requests access to a protected
resource it hands-over the bearer token to the resource server.
The OAuth 2.0 Proof-of-Possession security concept extends bearer
token security and requires the client to demonstrate possession of a
key when accessing a protected resource.
This document describes how the client obtains this keying material
from the authorization server.
https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-key-distribution/
https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-03
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-pop-key-distribution-03
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Phil Hunt]

I have been wondering about that myself. Interest seems to wained with the TOKBIND work emerging. Maybe I am wrong about that?

Phil

Oracle Corporation, Identity Cloud Services & Identity Standards
@independentid

Post by John Bradley
I updated the references but haven't made any other changes.
I had some questions about it so though it was worth keeping alive at-least for discussion.
There have been some other questions and proposed changes.
I will take a look through them and see if what may be worth updating.
John B.

Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-key-distribution-03.txt
Date: February 24, 2017 at 6:55:25 PM GMT-3
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol of the IETF.
Title : OAuth 2.0 Proof-of-Possession: Authorization Server to Client Key Distribution
Authors : John Bradley
Phil Hunt
Michael B. Jones
Hannes Tschofenig
Filename : draft-ietf-oauth-pop-key-distribution-03.txt
Pages : 18
Date : 2017-02-24
RFC 6750 specified the bearer token concept for securing access to
protected resources. Bearer tokens need to be protected in transit
as well as at rest. When a client requests access to a protected
resource it hands-over the bearer token to the resource server.
The OAuth 2.0 Proof-of-Possession security concept extends bearer
token security and requires the client to demonstrate possession of a
key when accessing a protected resource.
This document describes how the client obtains this keying material
from the authorization server.
https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-key-distribution/ <https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-key-distribution/>
https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-03
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-pop-key-distribution-03
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

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

[John Bradley]

The European banks are interested in mutual TLS for server to server connections as part of PSD2/Open Banking.

They have been thinking that they would have central CA and directly use CA certificates for all the legs.

I sent them this to get them thinking that they could perhaps secure the token endpoint with cert based mutual TLS but allow clients to specify there own keys for access tokens to make key rotation and deployment easier.

I was also think ing that they could protect a jwks_uri with the CA certificate using OCSP stapling and then use mutual TLS to the token endpoint based on keyid and/or fingerprint. allowing for rotation of keys to token endpoint and better support clusters with multiple keys.

I don’t think this has much interest outside of some verticals like financials.

John B.

Post by Phil Hunt
I have been wondering about that myself. Interest seems to wained with the TOKBIND work emerging. Maybe I am wrong about that?
Phil
Oracle Corporation, Identity Cloud Services & Identity Standards
@independentid

Post by John Bradley
I updated the references but haven't made any other changes.
I had some questions about it so though it was worth keeping alive at-least for discussion.
There have been some other questions and proposed changes.
I will take a look through them and see if what may be worth updating.
John B.

Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-key-distribution-03.txt
Date: February 24, 2017 at 6:55:25 PM GMT-3
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol of the IETF.
Title : OAuth 2.0 Proof-of-Possession: Authorization Server to Client Key Distribution
Authors : John Bradley
Phil Hunt
Michael B. Jones
Hannes Tschofenig
Filename : draft-ietf-oauth-pop-key-distribution-03.txt
Pages : 18
Date : 2017-02-24
RFC 6750 specified the bearer token concept for securing access to
protected resources. Bearer tokens need to be protected in transit
as well as at rest. When a client requests access to a protected
resource it hands-over the bearer token to the resource server.
The OAuth 2.0 Proof-of-Possession security concept extends bearer
token security and requires the client to demonstrate possession of a
key when accessing a protected resource.
This document describes how the client obtains this keying material
from the authorization server.
https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-key-distribution/ <https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-key-distribution/>
https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-03 <https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-03>
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-pop-key-distribution-03
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

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

[Nat Sakimura]

+1

Token binding is good, but there are infrastructures that cannot deploy it
while they still need HoK in some manner.
It could be a short term thing -- perhaps 3 years, but they have to do it
now so...

I have a question about the draft.

In section 5.1, `key` is optional and when it is omitted, the server
creates a ephemeral key pair for the client.
My question is: how do you send the ephemeral private key securely to the
client?
I suppose it is returned in the similar fashion as in the case of the
symmetric, but it is not clear from my read.

Also, at that point, the authorization server has everything needed to
impersonate the client, which may not be desirable.
Is it not simpler and better to REQUIRE the `key` parameter?

Nat

Post by John Bradley
The European banks are interested in mutual TLS for server to server
connections as part of PSD2/Open Banking.
They have been thinking that they would have central CA and directly use
CA certificates for all the legs.
I sent them this to get them thinking that they could perhaps secure the
token endpoint with cert based mutual TLS but allow clients to specify
there own keys for access tokens to make key rotation and deployment easier.
I was also think ing that they could protect a jwks_uri with the CA
certificate using OCSP stapling and then use mutual TLS to the token
endpoint based on keyid and/or fingerprint. allowing for rotation of keys
to token endpoint and better support clusters with multiple keys.
I don’t think this has much interest outside of some verticals like financials.
John B.
I have been wondering about that myself. Interest seems to wained with the
TOKBIND work emerging. Maybe I am wrong about that?
Phil
Oracle Corporation, Identity Cloud Services & Identity Standards
@independentid
www.independentid.com
I updated the references but haven't made any other changes.
I had some questions about it so though it was worth keeping alive at-least for discussion.
There have been some other questions and proposed changes.
I will take a look through them and see if what may be worth updating.
John B.
draft-ietf-oauth-pop-key-distribution-03.txt*
*Date: *February 24, 2017 at 6:55:25 PM GMT-3
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol of the IETF.
Title : OAuth 2.0 Proof-of-Possession: Authorization
Server to Client Key Distribution
Authors : John Bradley
Phil Hunt
Michael B. Jones
Hannes Tschofenig
Filename : draft-ietf-oauth-pop-key-distribution-03.txt
Pages : 18
Date : 2017-02-24
RFC 6750 specified the bearer token concept for securing access to
protected resources. Bearer tokens need to be protected in transit
as well as at rest. When a client requests access to a protected
resource it hands-over the bearer token to the resource server.
The OAuth 2.0 Proof-of-Possession security concept extends bearer
token security and requires the client to demonstrate possession of a
key when accessing a protected resource.
This document describes how the client obtains this keying material
from the authorization server.
https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-key-distribution/
https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-03
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-pop-key-distribution-03
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[John Bradley]

The private key is encrypted to the client. If the attacker has the
symmetric key then it would get the proof key.

I prefer the client to always provide the key, however some people believe
that mobile devices can't reliably create secure key, and it is better to
have the server create the keypair.

In both cases you are relying on the client authentication or PKCE to bind
to the correct client.

They are more or less equivalent. I prefer the private key to never leave
the device personally.

This has been debated several times.

John B.

On Mar 3, 2017 12:15 AM, "Nat Sakimura" <***@gmail.com> wrote:

+1

Token binding is good, but there are infrastructures that cannot deploy it
while they still need HoK in some manner.
It could be a short term thing -- perhaps 3 years, but they have to do it
now so...

I have a question about the draft.

In section 5.1, `key` is optional and when it is omitted, the server
creates a ephemeral key pair for the client.
My question is: how do you send the ephemeral private key securely to the
client?
I suppose it is returned in the similar fashion as in the case of the
symmetric, but it is not clear from my read.

Also, at that point, the authorization server has everything needed to
impersonate the client, which may not be desirable.
Is it not simpler and better to REQUIRE the `key` parameter?

Nat

Post by John Bradley
The European banks are interested in mutual TLS for server to server
connections as part of PSD2/Open Banking.
They have been thinking that they would have central CA and directly use
CA certificates for all the legs.
I sent them this to get them thinking that they could perhaps secure the
token endpoint with cert based mutual TLS but allow clients to specify
there own keys for access tokens to make key rotation and deployment easier.
I was also think ing that they could protect a jwks_uri with the CA
certificate using OCSP stapling and then use mutual TLS to the token
endpoint based on keyid and/or fingerprint. allowing for rotation of keys
to token endpoint and better support clusters with multiple keys.
I don’t think this has much interest outside of some verticals like financials.
John B.
I have been wondering about that myself. Interest seems to wained with the
TOKBIND work emerging. Maybe I am wrong about that?
Phil
Oracle Corporation, Identity Cloud Services & Identity Standards
@independentid
www.independentid.com
I updated the references but haven't made any other changes.
I had some questions about it so though it was worth keeping alive at-least for discussion.
There have been some other questions and proposed changes.
I will take a look through them and see if what may be worth updating.
John B.
draft-ietf-oauth-pop-key-distribution-03.txt*
*Date: *February 24, 2017 at 6:55:25 PM GMT-3
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol of the IETF.
Title : OAuth 2.0 Proof-of-Possession: Authorization
Server to Client Key Distribution
Authors : John Bradley
Phil Hunt
Michael B. Jones
Hannes Tschofenig
Filename : draft-ietf-oauth-pop-key-distribution-03.txt
Pages : 18
Date : 2017-02-24
RFC 6750 specified the bearer token concept for securing access to
protected resources. Bearer tokens need to be protected in transit
as well as at rest. When a client requests access to a protected
resource it hands-over the bearer token to the resource server.
The OAuth 2.0 Proof-of-Possession security concept extends bearer
token security and requires the client to demonstrate possession of a
key when accessing a protected resource.
This document describes how the client obtains this keying material
from the authorization server.
https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-key-distribution/
https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-03
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-pop-key-distribution-03
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Nat Sakimura]

Thanks John.

Perhaps you can add the discussion to the security consideration.

I understand the issue with mobile clients inability to get a good random
but the shift of key generation point would have a large impact on the
liability shift as well so I would probably profile it down always to
require keys to be generated by the client.

From editorial point of view, I would appreciate if you can put

sub-headings to each topics dealt in 7. Security Considerations.

Best,

Nat

The private key is encrypted to the client. If the attacker has the
symmetric key then it would get the proof key.
I prefer the client to always provide the key, however some people believe
that mobile devices can't reliably create secure key, and it is better to
have the server create the keypair.
In both cases you are relying on the client authentication or PKCE to bind
to the correct client.
They are more or less equivalent. I prefer the private key to never
leave the device personally.
This has been debated several times.
John B.
+1
Token binding is good, but there are infrastructures that cannot deploy it
while they still need HoK in some manner.
It could be a short term thing -- perhaps 3 years, but they have to do it
now so...
I have a question about the draft.
In section 5.1, `key` is optional and when it is omitted, the server
creates a ephemeral key pair for the client.
My question is: how do you send the ephemeral private key securely to the
client?
I suppose it is returned in the similar fashion as in the case of the
symmetric, but it is not clear from my read.
Also, at that point, the authorization server has everything needed to
impersonate the client, which may not be desirable.
Is it not simpler and better to REQUIRE the `key` parameter?
Nat
The European banks are interested in mutual TLS for server to server
connections as part of PSD2/Open Banking.
They have been thinking that they would have central CA and directly use
CA certificates for all the legs.
I sent them this to get them thinking that they could perhaps secure the
token endpoint with cert based mutual TLS but allow clients to specify
there own keys for access tokens to make key rotation and deployment easier.
I was also think ing that they could protect a jwks_uri with the CA
certificate using OCSP stapling and then use mutual TLS to the token
endpoint based on keyid and/or fingerprint. allowing for rotation of keys
to token endpoint and better support clusters with multiple keys.
I don’t think this has much interest outside of some verticals like financials.
John B.
I have been wondering about that myself. Interest seems to wained with the
TOKBIND work emerging. Maybe I am wrong about that?
Phil
Oracle Corporation, Identity Cloud Services & Identity Standards
@independentid
www.independentid.com
I updated the references but haven't made any other changes.
I had some questions about it so though it was worth keeping alive at-least for discussion.
There have been some other questions and proposed changes.
I will take a look through them and see if what may be worth updating.
John B.
draft-ietf-oauth-pop-key-distribution-03.txt*
*Date: *February 24, 2017 at 6:55:25 PM GMT-3
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol of the IETF.
Title : OAuth 2.0 Proof-of-Possession: Authorization
Server to Client Key Distribution
Authors : John Bradley
Phil Hunt
Michael B. Jones
Hannes Tschofenig
Filename : draft-ietf-oauth-pop-key-distribution-03.txt
Pages : 18
Date : 2017-02-24
RFC 6750 specified the bearer token concept for securing access to
protected resources. Bearer tokens need to be protected in transit
as well as at rest. When a client requests access to a protected
resource it hands-over the bearer token to the resource server.
The OAuth 2.0 Proof-of-Possession security concept extends bearer
token security and requires the client to demonstrate possession of a
key when accessing a protected resource.
This document describes how the client obtains this keying material
from the authorization server.
https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-key-distribution/
https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-03
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-pop-key-distribution-03
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
--
Nat Sakimura
Chairman of the Board, OpenID Foundation
--

Nat Sakimura

Chairman of the Board, OpenID Foundation

[Anthony Nadalin]

I also think that this can be useful outside of Token Binding as this we have been looking at use cases for offline access tokens (or ID Tokens), and this sort of forms the basis for this approach

From: OAuth [mailto:oauth-***@ietf.org] On Behalf Of Nat Sakimura
Sent: Thursday, March 2, 2017 7:16 PM
To: John Bradley <***@ve7jtb.com>; Phil Hunt <***@oracle.com>
Cc: <***@ietf.org> <***@ietf.org>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-key-distribution-03.txt

+1

Token binding is good, but there are infrastructures that cannot deploy it while they still need HoK in some manner.
It could be a short term thing -- perhaps 3 years, but they have to do it now so...

I have a question about the draft.

In section 5.1, `key` is optional and when it is omitted, the server creates a ephemeral key pair for the client.
My question is: how do you send the ephemeral private key securely to the client?
I suppose it is returned in the similar fashion as in the case of the symmetric, but it is not clear from my read.

Also, at that point, the authorization server has everything needed to impersonate the client, which may not be desirable.
Is it not simpler and better to REQUIRE the `key` parameter?

Nat

On Sat, Feb 25, 2017 at 8:51 AM John Bradley <***@ve7jtb.com<mailto:***@ve7jtb.com>> wrote:
The European banks are interested in mutual TLS for server to server connections as part of PSD2/Open Banking.

They have been thinking that they would have central CA and directly use CA certificates for all the legs.

I sent them this to get them thinking that they could perhaps secure the token endpoint with cert based mutual TLS but allow clients to specify there own keys for access tokens to make key rotation and deployment easier.

I was also think ing that they could protect a jwks_uri with the CA certificate using OCSP stapling and then use mutual TLS to the token endpoint based on keyid and/or fingerprint. allowing for rotation of keys to token endpoint and better support clusters with multiple keys.

I don’t think this has much interest outside of some verticals like financials.

John B.
On Feb 24, 2017, at 8:33 PM, Phil Hunt <***@oracle.com<mailto:***@oracle.com>> wrote:

I have been wondering about that myself. Interest seems to wained with the TOKBIND work emerging. Maybe I am wrong about that?

Phil

Oracle Corporation, Identity Cloud Services & Identity Standards
@independentid
www.independentid.com<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.independentid.com%2F&data=02%7C01%7Ctonynad%40microsoft.com%7Ca66d0b3d54d247111dc808d461e39980%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636241077561026937&sdata=WdNY8UBy5lYNF7Lmi9ryxxRg4P%2BgPOTXoAQlcZVE%2FU0%3D&reserved=0>
***@oracle.com<mailto:***@oracle.com>






On Feb 24, 2017, at 1:58 PM, John Bradley <***@ve7jtb.com<mailto:***@ve7jtb.com>> wrote:

I updated the references but haven't made any other changes.

I had some questions about it so though it was worth keeping alive at-least for discussion.

There have been some other questions and proposed changes.

I will take a look through them and see if what may be worth updating.

John B.


Begin forwarded message:

From: internet-***@ietf.org<mailto:internet-***@ietf.org>
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-key-distribution-03.txt
Date: February 24, 2017 at 6:55:25 PM GMT-3
To: <i-d-***@ietf.org<mailto:i-d-***@ietf.org>>
Cc: ***@ietf.org<mailto:***@ietf.org>


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol of the IETF.

Title : OAuth 2.0 Proof-of-Possession: Authorization Server to Client Key Distribution
Authors : John Bradley
Phil Hunt
Michael B. Jones
Hannes Tschofenig
Filename : draft-ietf-oauth-pop-key-distribution-03.txt
Pages : 18
Date : 2017-02-24

Abstract:
RFC 6750 specified the bearer token concept for securing access to
protected resources. Bearer tokens need to be protected in transit
as well as at rest. When a client requests access to a protected
resource it hands-over the bearer token to the resource server.

The OAuth 2.0 Proof-of-Possession security concept extends bearer
token security and requires the client to demonstrate possession of a
key when accessing a protected resource.

This document describes how the client obtains this keying material
from the authorization server.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-key-distribution/<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-oauth-pop-key-distribution%2F&data=02%7C01%7Ctonynad%40microsoft.com%7Ca66d0b3d54d247111dc808d461e39980%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636241077561026937&sdata=hu6Vig%2F9GTVDuQoy9Wk7wlTamxQwQTsJJqhtUJnVLkE%3D&reserved=0>

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-03<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-oauth-pop-key-distribution-03&data=02%7C01%7Ctonynad%40microsoft.com%7Ca66d0b3d54d247111dc808d461e39980%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636241077561026937&sdata=1AyBrKFxeypPNRhi9KNOS4f%2FjwbZ%2Bx2QX2LtKk7zusw%3D&reserved=0>

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-pop-key-distribution-03<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-oauth-pop-key-distribution-03&data=02%7C01%7Ctonynad%40microsoft.com%7Ca66d0b3d54d247111dc808d461e39980%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636241077561026937&sdata=nbBRocKxUgfGc5UG9cJyvPTzAOv%2BOMSBocPBes9ysXE%3D&reserved=0>


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftools.ietf.org&data=02%7C01%7Ctonynad%40microsoft.com%7Ca66d0b3d54d247111dc808d461e39980%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636241077561026937&sdata=Wtts0UG8f5HTb9G8YM4pTufGP6rFvnfnIHvi1Asnahs%3D&reserved=0>.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
OAuth mailing list
***@ietf.org<mailto:***@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7Ctonynad%40microsoft.com%7Ca66d0b3d54d247111dc808d461e39980%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636241077561026937&sdata=uTKQATJVoX%2FRvCBkGJOv44KmXMuq0z3GvOgio%2BPNA4E%3D&reserved=0>

_______________________________________________
OAuth mailing list
***@ietf.org<mailto:***@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7Ctonynad%40microsoft.com%7Ca66d0b3d54d247111dc808d461e39980%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636241077561026937&sdata=uTKQATJVoX%2FRvCBkGJOv44KmXMuq0z3GvOgio%2BPNA4E%3D&reserved=0>


_______________________________________________
OAuth mailing list
***@ietf.org<mailto:***@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7Ctonynad%40microsoft.com%7Ca66d0b3d54d247111dc808d461e39980%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636241077561026937&sdata=uTKQATJVoX%2FRvCBkGJOv44KmXMuq0z3GvOgio%2BPNA4E%3D&reserved=0>

[Ludwig Seitz]

Post by John Bradley
I updated the references but haven't made any other changes.
I had some questions about it so though it was worth keeping alive at-least for discussion.
There have been some other questions and proposed changes.
I will take a look through them and see if what may be worth updating.
John B.

Question about the 'aud' parameter: Wouldn't it be useful to allow other
values than URIs for that one?

One could easily imagine a group identifier as value of that field,
where the RS internally resolves whether it is part of that group and
therefore the target audience of that token.

Regards,

Ludwig

[John Bradley]

We rethought aud in https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators

We wanted it to work with bearer tokens so that the AS could put a audience in the token that could not be faked by a malicious RS.
For the bearer token use case it needs to be a URI to avoid the client being tricked.

For a PoP token it could be logical if the token proof presentment mechanism is secure against RS spoofing.

Presentment mechanisms that are bound to TLS by a EKM or via mutual TLS are OK.
At the application layer the presentment would need sign over the resource URI to prevent forwarding.
Something that used only a signature over a challenge would still rely on there being a unspoofable audience in the AT itself.

You could securely do a secure logical resource for bearer.

It could be something like the RS would provide its logical resource URI as part of a authenticate response along with the scopes required.

The client could de-refrence the logical scope URI to retrieve a JSON object containing back pointers to the physical resource URI covered by that logical audience.
It could also contain other RS meta-data.

We do something like that in connect to allow multiple redirect URI to generate the same pairwise identifier.
http://openid.net/specs/openid-connect-registration-1_0.html#SectorIdentifierValidation <http://openid.net/specs/openid-connect-registration-1_0.html#SectorIdentifierValidation>

RS discovery has been shuffled aside in the WG foe the moment.

I would be OK with res/aud being a logical identifier if it points to meta-data like aud in id_tokens points to meta-data for the AS.

I think making res/aud a free form string would come back and bite us on the ass.

John B.

Post by John Bradley
I updated the references but haven't made any other changes.
I had some questions about it so though it was worth keeping alive
at-least for discussion.
There have been some other questions and proposed changes.
I will take a look through them and see if what may be worth updating.
John B.

Question about the 'aud' parameter: Wouldn't it be useful to allow other values than URIs for that one?
One could easily imagine a group identifier as value of that field, where the RS internally resolves whether it is part of that group and therefore the target audience of that token.
Regards,
Ludwig
--
Ludwig Seitz, PhD
Security Lab, RISE ICT/SICS
Phone [phone]
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth