date:20161112

Re: [OAUTH-WG] Using Referred Token Binding ID for Token Binding of Access Tokens

2016-11-12 Thread Mike Jones

The HTTP header is described in 
https://tools.ietf.org/html/draft-ietf-tokbind-https-06#section-2 where it 
talks about a Sec-Token-Binding Header Field with a TokenBindingMessage with a 
TokenBinding structure with TokenBindingType of referred_token_binding.

The example is a good idea.

   -- Mike

From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Sunday, November 13, 2016 2:48 PM
To: Mike Jones ; oauth@ietf.org
Subject: Re: [OAUTH-WG] Using Referred Token Binding ID for Token Binding of 
Access Tokens

Hi Mike,

does this mean the binding ID is indicated to the authorization server via a 
respective HTTP header? I'm asking because I didn't find the respective 
parameter in the draft.

Could you add a HTTP request example? I think that would help a lot to better 
understand the mechanism.

best regards,
Torsten.
Am 20.09.2016 um 21:16 schrieb Mike Jones:
The OAuth Token Binding specification has been revised to use the Referred 
Token Binding ID when performing token binding of access tokens.  This was 
enabled by the Implementation Considerations in the Token Binding HTTPS 
specification being added to make it clear that Token Binding implementations 
will enable using the Referred Token Binding ID in this manner.  Protected 
Resource Metadata was also defined.

Thanks to Brian Campbell for clarifications on the differences between token 
binding of access tokens issued from the authorization endpoint versus those 
issued from the token endpoint.

The specification is available at:

*   http://tools.ietf.org/html/draft-ietf-oauth-token-binding-01

An HTML-formatted version is also available at:

*   http://self-issued.info/docs/draft-ietf-oauth-token-binding-01.html

   -- Mike

P.S.  This notice was also posted at http://self-issued.info/?p=1610 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] Comments on draft-jones-oauth-resource-metadata-00

2016-11-12 Thread Mike Jones

Actually, it's intentionally a particular resource that the metadata applies to 
- exactly as the AS metadata applies to a particular AS.  It is *not* metadata 
about all resources that might be managed by a resource server, just as the AS 
metadata is not about all ASs that a particular server (such as a multi-tenant 
server) might manage.

Bear in mind that just as different ASs are likely to use different keys for 
security reasons, even if they are on the same physical server - such as in the 
multi-tenant case, different resources need to be able to use different keys, 
even if they are hosted at the same resource server.  That mandates the 
metadata being resource-specific.

For what it's worth, if we ever do an OAuth 3.0, I believe we should get rid of 
the "resource server" term entirely.  It doesn't have any actionable semantics 
tied to it and its existence only encourages confusion.

Thanks for reading the draft, Torsten.

   -- Mike

From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Sunday, November 13, 2016 2:32 PM
To: Mike Jones ; oauth@ietf.org
Cc: gffle...@aol.com
Subject: Re: [OAUTH-WG] Comments on draft-jones-oauth-resource-metadata-00

Hi Mike,

just read your spec and I'm also a bit confused about the "resource" meta data 
element in section 2.

I would assume the metadata are provided for a certain resource server managing 
a set of resources in a particular administrative domain. So I would prefer to 
name the respective element "resource_server". In the example George gave the 
URL would be "https://idp.example.com/tenant//". Resource managed by 
a particular resource server could use sub-paths of the respective URL, such as 
" https://idp.example.com/tenant//users/".

best regards,
Torsten.
Am 05.08.2016 um 02:10 schrieb George Fletcher:
Mike, thanks for drafting and publishing these specifications. I have a couple 
of questions regarding the draft-jones-oauth-resource-metadata-00.

1. Is a "protected resource" a server? or an actual API endpoint. The 
non-normative examples use /.well-known/oauth-protected-resource and 
/resource1/.well-known/oauth-protected-resource which is a little unclear. I 
think of "resource" as something like "Mail" or "Instant Messaging".

2. Assuming that "protected resource" means an actual API endpoint, what is the 
expected location of the metadata for a fully REST compliant API where the full 
URL points to a specific resource and not the concept of a general API.
Using an example of an IdP that supports user management capabilities. Let's 
assume the IdP supports a REST API of...

CREATE -- POST https://idp.example.com/tenant//users
READ -- GET https://idp.example.com/tenant//users/
UPDATE -- PUT https://idp.example.com/tenant//users/
DELETE -- DELETE https://idp.example.com/tenant//users/

Assuming there are 3 tenants (tenantA, tenantB, tenantB) and lots of users. 
Where does the .well-known/oauth-protected-resource get added?

   ?? 
https://idp.example.com/tenant/tenantA/users/1232234/.well-known/oauth-protected-resource

In this case would not the oauth-protected-resource metadata be duplicated 
across the set of tenants and users? Is that the desired behavior?
Thanks,
George




___

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] OAuth: the ABC attack (the Alice and Bob Collusion attack)

2016-11-12 Thread Torsten Lodderstedt

I agree, we should analyse the threat. From my first impression it feels 
like injection with some specialties.


@Denis:
So far, I'm struggeling to understand how this attack is performed from 
a practical perspective. Every token/assertion issued to the uncle is 
bound to its identity. So it the niece wants to "upgrade" her age, she 
would need to somehow mix identity data for two identities (her's and 
her uncle's identity) into a single token, which needs to be signed by 
the respective AS. How is this gone work?


kind regards,
Torsten.

Am 11.11.2016 um 16:27 schrieb Nat Sakimura:
Thanks Denis for pointing it out. It may be desirable to add ABC 
attack to the list of threats. Torsten et al. are updating Threat 
Model and Security Considerations so it could potentially be included 
in there.


Some remarks:

  * I suppose the assumption is that the Bob does not share his
credentials with Alice: Otherwise, sharing the credential would
achieve something worse.
  * In addition, it assumes that Bob does not give his device to
Alice: Otherwise, something similar to ABC attack can be achieved
by Bob giving Alice his Laptop or Phone, and I guess this happens
more often than shipping Bob's access token to Alice.
  * With these assumptions:
  o It looks like a variation of token injection attack that we
have been talking about for many years.
  o If we token bind the refresh and access tokens, the ABC attack
as described does not work.
  o For something like Age verification, recognizing such attacks,
it probably is a bad practice to rely on refresh/access token.
The service should do more active check, e.g., through OpenID
Connect.

Best,

Nat

On Tue, Nov 8, 2016 at 2:54 AM Denis > wrote:


Section 5 of "draft-ietf-oauth-pop-architecture-08.txt" identifies
requirements.
One of them (which, BTW, should be moved into Section 4 - Threats)
is :

Collusion:

Resource servers that collude ...

This threat addresses the case of "/collusion between servers"/
while the case of "/collusion between clients"/
has not been considered. When access tokens are being used,
/collusion between clients /is of primary importance.

Let us consider the following "Alice and Bob Collusion attack"
(ABC attack).

An uncle (Bob) is willing to collaborate with his young niece
(Alice) who is less than 18 during a short period of time.
The niece is opening her own session and creates an account on a
server. The uncle does not hand over his own session to her niece
at any point of time.

Let us assume that some crypto expert has written two specific
pieces of software. One has been installed on the laptop
of the uncle and another one on the laptop of the niece. The two
laptops are able to communicate using a network (e.g. a WAN or a LAN).

The niece creates an account on a resource server. Later on, the
resource server asks her (or him ?) to demonstrate that she (or
his ?)
is more than 18. She forwards the information received from the
resource server to her uncle using the network. The uncle receives
that information and connects to an Authorization Server. The
uncle requests an access token containing information demonstrating
that he is older than 18 and passed it back to his niece. The
niece then presents it to the resource server. The access token is
accepted.

Since the niece has been able to demonstrate once that she is more
than 18, the resource server will remember this attribute
and in the future she will not need to demonstrate it again. She
will keep the advantages related to this attribute associated
with her account on that resource server until she does not need
it anymore, i.e. when she will really be over 18.

Whatever kind of cryptographic is being used, when two users
collaborate, a software-only solution will be
unable to prevent the transfer of an attribute of a user that
possess it to another user that does not possess it .

The use of a secure element simply protecting the confidentiality
and the integrity of some secret key or private key will be
ineffective
to counter the Alice and Bob collusion attack. Additional
properties will be required for the secure element.

RFC 6819 (OAuth 2.0 Threat Model and Security Considerations)
issued in January 2013 has omitted to take into consideration
the Alice and Bob Collusion attack.

Section 2.3 of the ABC4Trust project about key-binding in
Deliverable D2.2 available at:
https://abc4trust.eu/download/Deliverable_D2.2.pdf states on page 17 :

To prevent “credential pooling”, i.e., multiple Users sharing
their credentials, credentials can optionally be bound to a secret
key,
i.e. a cryptographically strong random value

Re: [OAUTH-WG] New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt

2016-11-12 Thread Torsten Lodderstedt

I understand. My point is different: the text seems to assume everybody 
is using client registration, but that's not the case. I would like to 
point out it makes sense to explicitely state the assumption that it is 
determined by client policy (indepedent of the way this policy is 
established).

Am 13.11.2016 um 14:24 schrieb Justin Richer:
As part of the client’s registered data model. At least, based on how 
our own implementation works (where we support client_secret_basic, 
private_key_jwt, etc), that’s where we’d check to see if the client 
was supposed to be using TLS auth or not.

We don’t let clients switch away from their registered auth mechanism.

 — Justin

On Nov 13, 2016, at 2:21 PM, Torsten Lodderstedt 
> wrote:

Justin,

Am 13.11.2016 um 13:39 schrieb Justin Richer:
Torsten, I believe this is intended to be triggered by the 
tls_client_auth value specified in §3.

in the token request?

Nit on that section, the field name for the client metadata in 
RFC7591 is token_endpoint_auth_method, the _supported version is 
from the corresponding discovery document.

 — Justin

Torsten.
On Nov 13, 2016, at 12:31 PM, Torsten Lodderstedt 
> wrote:

Hi John and Brian,

thanks for writting this draft.

One question: how does the AS determine the authentication method 
is TLS authentication? I think you assume this is defined by the 
client-specific policy, independent of whether the client is 
registered automatically or manually. Would you mind to explicitely 
state this in the draft?

best regards,
Torsten.

Am 11.10.2016 um 05:59 schrieb John Bradley:
At the request of the OpenID Foundation Financial Services API 
Working group, Brian Campbell and I have documented
mutual TLS client authentication.   This is something that lots of 
people do in practice though we have never had a spec for it.

The Banks want to use it for some server to server API use cases 
being driven by new open banking regulation.

The largest thing in the draft is the IANA registration of 
“tls_client_auth” Token Endpoint authentication method for use in 
Registration and discovery.

The trust model is intentionally left open so that you could use a 
“common name” and a restricted list of CA or a direct lookup of 
the subject public key against a reregistered value,  or something 
in between.

I hope that this is non controversial and the WG can adopt it quickly.

Regards
John B.

Begin forwarded message:

*From: *internet-dra...@ietf.org
*Subject: **New Version Notification for 
draft-campbell-oauth-tls-client-auth-00.txt*

*Date: *October 10, 2016 at 5:44:39 PM GMT-3
*To: *"Brian Campbell" , "John 
Bradley" >

A new version of I-D, draft-campbell-oauth-tls-client-auth-00.txt
has been successfully submitted by John Bradley and posted to the
IETF repository.

Name:draft-campbell-oauth-tls-client-auth
Revision:00
Title:Mutual X.509 Transport Layer Security (TLS) Authentication 
for OAuth Clients

Document date:2016-10-10
Group:Individual Submission
Pages:5
URL: 
https://www.ietf.org/internet-drafts/draft-campbell-oauth-tls-client-auth-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-campbell-oauth-tls-client-auth/
Htmlized: 
https://tools.ietf.org/html/draft-campbell-oauth-tls-client-auth-00

Abstract:
  This document describes X.509 certificates as OAuth client
  credentials using Transport Layer Security (TLS) mutual
  authentication as a mechanism for client authentication to the
  authorization server's token endpoint.

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 .

The IETF Secretariat

___
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] Comments on draft-jones-oauth-resource-metadata-00

2016-11-12 Thread Torsten Lodderstedt


Hi Mike,

just read your spec and I'm also a bit confused about the "resource" 
meta data element in section 2.


I would assume the metadata are provided for a certain resource server 
managing a set of resources in a particular administrative domain. So I 
would prefer to name the respective element "resource_server". In the 
example George gave the URL would be 
"https://idp.example.com/tenant//". Resource managed by a 
particular resource server could use sub-paths of the respective URL, 
such as " https://idp.example.com/tenant//users/".


best regards,
Torsten.

Am 05.08.2016 um 02:10 schrieb George Fletcher:
Mike, thanks for drafting and publishing these specifications. I have 
a couple of questions regarding the 
draft-jones-oauth-resource-metadata-00.


1. Is a "protected resource" a server? or an actual API endpoint. The 
non-normative examples use /.well-known/oauth-protected-resource and 
/resource1/.well-known/oauth-protected-resource which is a little 
unclear. I think of "resource" as something like "Mail" or "Instant 
Messaging".


2. Assuming that "protected resource" means an actual API endpoint, 
what is the expected location of the metadata for a fully REST 
compliant API where the full URL points to a specific resource and not 
the concept of a general API.


Using an example of an IdP that supports user management
capabilities. Let's assume the IdP supports a REST API of...

CREATE -- POST https://idp.example.com/tenant//users
READ -- GET
https://idp.example.com/tenant//users/
UPDATE --
PUThttps://idp.example.com/tenant//users/
DELETE --
DELETEhttps://idp.example.com/tenant//users/

Assuming there are 3 tenants (tenantA, tenantB, tenantB) and lots
of users. Where does the .well-known/oauth-protected-resource get
added?

   ??

https://idp.example.com/tenant/tenantA/users/1232234/.well-known/oauth-protected-resource

In this case would not the oauth-protected-resource metadata be
duplicated across the set of tenants and users? Is that the
desired behavior?

Thanks,
George


___
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] New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt

2016-11-12 Thread Justin Richer

As part of the client’s registered data model. At least, based on how our own 
implementation works (where we support client_secret_basic, private_key_jwt, 
etc), that’s where we’d check to see if the client was supposed to be using TLS 
auth or not.

We don’t let clients switch away from their registered auth mechanism.

 — Justin

> On Nov 13, 2016, at 2:21 PM, Torsten Lodderstedt  
> wrote:
> 
> Justin,
> 
> Am 13.11.2016 um 13:39 schrieb Justin Richer:
>> Torsten, I believe this is intended to be triggered by the tls_client_auth 
>> value specified in §3. 
> 
> in the token request?
> 
>> 
>> Nit on that section, the field name for the client metadata in RFC7591 is 
>> token_endpoint_auth_method, the _supported version is from the corresponding 
>> discovery document.
>> 
>>  — Justin
>> 
> Torsten.
>>> On Nov 13, 2016, at 12:31 PM, Torsten Lodderstedt >> > wrote:
>>> 
>>> Hi John and Brian,
>>> 
>>> thanks for writting this draft.
>>> 
>>> One question: how does the AS determine the authentication method is TLS 
>>> authentication? I think you assume this is defined by the client-specific 
>>> policy, independent of whether the client is registered automatically or 
>>> manually. Would you mind to explicitely state this in the draft?
>>> 
>>> best regards,
>>> Torsten.
>>> 
>>> Am 11.10.2016 um 05:59 schrieb John Bradley:
 At the request of the OpenID Foundation Financial Services API Working 
 group, Brian Campbell and I have documented 
 mutual TLS client authentication.   This is something that lots of people 
 do in practice though we have never had a spec for it.
 
 The Banks want to use it for some server to server API use cases being 
 driven by new open banking regulation.
 
 The largest thing in the draft is the IANA registration of 
 “tls_client_auth” Token Endpoint authentication method for use in 
 Registration and discovery.
 
 The trust model is intentionally left open so that you could use a “common 
 name” and a restricted list of CA or a direct lookup of the subject public 
 key against a reregistered value,  or something in between.
 
 I hope that this is non controversial and the WG can adopt it quickly.
 
 Regards
 John B.
 
 
 
 
> Begin forwarded message:
> 
> From:  internet-dra...@ietf.org 
> 
> Subject: New Version Notification for 
> draft-campbell-oauth-tls-client-auth-00.txt
> Date: October 10, 2016 at 5:44:39 PM GMT-3
> To: "Brian Campbell"  >, "John Bradley"  >
> 
> 
> A new version of I-D, draft-campbell-oauth-tls-client-auth-00.txt
> has been successfully submitted by John Bradley and posted to the
> IETF repository.
> 
> Name: draft-campbell-oauth-tls-client-auth
> Revision: 00
> Title:Mutual X.509 Transport Layer Security (TLS) 
> Authentication for OAuth Clients
> Document date:2016-10-10
> Group:Individual Submission
> Pages:5
> URL:
> https://www.ietf.org/internet-drafts/draft-campbell-oauth-tls-client-auth-00.txt
>  
> 
> Status: 
> https://datatracker.ietf.org/doc/draft-campbell-oauth-tls-client-auth/ 
> 
> Htmlized:   
> https://tools.ietf.org/html/draft-campbell-oauth-tls-client-auth-00 
> 
> 
> 
> Abstract:
>   This document describes X.509 certificates as OAuth client
>   credentials using Transport Layer Security (TLS) mutual
>   authentication as a mechanism for client authentication to the
>   authorization server's token endpoint.
> 
> 
> 
> 
> 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 
> .
> 
> The IETF Secretariat
> 
 
 
 
 ___
 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

Re: [OAUTH-WG] New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt

2016-11-12 Thread Torsten Lodderstedt

Justin,

Am 13.11.2016 um 13:39 schrieb Justin Richer:
Torsten, I believe this is intended to be triggered by the 
tls_client_auth value specified in §3.

in the token request?

Nit on that section, the field name for the client metadata in RFC7591 
is token_endpoint_auth_method, the _supported version is from the 
corresponding discovery document.

 — Justin

Torsten.
On Nov 13, 2016, at 12:31 PM, Torsten Lodderstedt 
> wrote:

Hi John and Brian,

thanks for writting this draft.

One question: how does the AS determine the authentication method is 
TLS authentication? I think you assume this is defined by the 
client-specific policy, independent of whether the client is 
registered automatically or manually. Would you mind to explicitely 
state this in the draft?

best regards,
Torsten.

Am 11.10.2016 um 05:59 schrieb John Bradley:
At the request of the OpenID Foundation Financial Services API 
Working group, Brian Campbell and I have documented
mutual TLS client authentication.   This is something that lots of 
people do in practice though we have never had a spec for it.

The Banks want to use it for some server to server API use cases 
being driven by new open banking regulation.

The largest thing in the draft is the IANA registration of 
“tls_client_auth” Token Endpoint authentication method for use in 
Registration and discovery.

The trust model is intentionally left open so that you could use a 
“common name” and a restricted list of CA or a direct lookup of the 
subject public key against a reregistered value,  or something in 
between.

I hope that this is non controversial and the WG can adopt it quickly.

Regards
John B.

Begin forwarded message:

*From: *internet-dra...@ietf.org
*Subject: **New Version Notification for 
draft-campbell-oauth-tls-client-auth-00.txt*

*Date: *October 10, 2016 at 5:44:39 PM GMT-3
*To: *"Brian Campbell" , "John Bradley" 
>

A new version of I-D, draft-campbell-oauth-tls-client-auth-00.txt
has been successfully submitted by John Bradley and posted to the
IETF repository.

Name:draft-campbell-oauth-tls-client-auth
Revision:00
Title:Mutual X.509 Transport Layer Security (TLS) Authentication 
for OAuth Clients

Document date:2016-10-10
Group:Individual Submission
Pages:5
URL: 
https://www.ietf.org/internet-drafts/draft-campbell-oauth-tls-client-auth-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-campbell-oauth-tls-client-auth/
Htmlized: 
https://tools.ietf.org/html/draft-campbell-oauth-tls-client-auth-00

Abstract:
  This document describes X.509 certificates as OAuth client
  credentials using Transport Layer Security (TLS) mutual
  authentication as a mechanism for client authentication to the
  authorization server's token endpoint.

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 
.

The IETF Secretariat

___
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] New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt

2016-11-12 Thread Justin Richer

Torsten, I believe this is intended to be triggered by the tls_client_auth 
value specified in §3. 

Nit on that section, the field name for the client metadata in RFC7591 is 
token_endpoint_auth_method, the _supported version is from the corresponding 
discovery document.

 — Justin

> On Nov 13, 2016, at 12:31 PM, Torsten Lodderstedt  
> wrote:
> 
> Hi John and Brian,
> 
> thanks for writting this draft.
> 
> One question: how does the AS determine the authentication method is TLS 
> authentication? I think you assume this is defined by the client-specific 
> policy, independent of whether the client is registered automatically or 
> manually. Would you mind to explicitely state this in the draft?
> 
> best regards,
> Torsten.
> 
> Am 11.10.2016 um 05:59 schrieb John Bradley:
>> At the request of the OpenID Foundation Financial Services API Working 
>> group, Brian Campbell and I have documented 
>> mutual TLS client authentication.   This is something that lots of people do 
>> in practice though we have never had a spec for it.
>> 
>> The Banks want to use it for some server to server API use cases being 
>> driven by new open banking regulation.
>> 
>> The largest thing in the draft is the IANA registration of “tls_client_auth” 
>> Token Endpoint authentication method for use in Registration and discovery.
>> 
>> The trust model is intentionally left open so that you could use a “common 
>> name” and a restricted list of CA or a direct lookup of the subject public 
>> key against a reregistered value,  or something in between.
>> 
>> I hope that this is non controversial and the WG can adopt it quickly.
>> 
>> Regards
>> John B.
>> 
>> 
>> 
>> 
>>> Begin forwarded message:
>>> 
>>> From:  internet-dra...@ietf.org 
>>> 
>>> Subject: New Version Notification for 
>>> draft-campbell-oauth-tls-client-auth-00.txt
>>> Date: October 10, 2016 at 5:44:39 PM GMT-3
>>> To: "Brian Campbell" < 
>>> brian.d.campb...@gmail.com 
>>> >, "John Bradley" >> >
>>> 
>>> 
>>> A new version of I-D, draft-campbell-oauth-tls-client-auth-00.txt
>>> has been successfully submitted by John Bradley and posted to the
>>> IETF repository.
>>> 
>>> Name:   draft-campbell-oauth-tls-client-auth
>>> Revision:   00
>>> Title:  Mutual X.509 Transport Layer Security (TLS) 
>>> Authentication for OAuth Clients
>>> Document date:  2016-10-10
>>> Group:  Individual Submission
>>> Pages:  5
>>> URL:
>>> https://www.ietf.org/internet-drafts/draft-campbell-oauth-tls-client-auth-00.txt
>>>  
>>> 
>>> Status: 
>>> https://datatracker.ietf.org/doc/draft-campbell-oauth-tls-client-auth/ 
>>> 
>>> Htmlized:   
>>> https://tools.ietf.org/html/draft-campbell-oauth-tls-client-auth-00 
>>> 
>>> 
>>> 
>>> Abstract:
>>>   This document describes X.509 certificates as OAuth client
>>>   credentials using Transport Layer Security (TLS) mutual
>>>   authentication as a mechanism for client authentication to the
>>>   authorization server's token endpoint.
>>> 
>>> 
>>> 
>>> 
>>> 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 
>>> .
>>> 
>>> The IETF Secretariat
>>> 
>> 
>> 
>> 
>> ___
>> 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] Fwd: New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt

2016-11-12 Thread Torsten Lodderstedt


Hi John and Brian,

thanks for writting this draft.

One question: how does the AS determine the authentication method is TLS 
authentication? I think you assume this is defined by the 
client-specific policy, independent of whether the client is registered 
automatically or manually. Would you mind to explicitely state this in 
the draft?


best regards,
Torsten.

Am 11.10.2016 um 05:59 schrieb John Bradley:
At the request of the OpenID Foundation Financial Services API Working 
group, Brian Campbell and I have documented
mutual TLS client authentication.   This is something that lots of 
people do in practice though we have never had a spec for it.


The Banks want to use it for some server to server API use cases being 
driven by new open banking regulation.


The largest thing in the draft is the IANA registration of 
“tls_client_auth” Token Endpoint authentication method for use in 
Registration and discovery.


The trust model is intentionally left open so that you could use a 
“common name” and a restricted list of CA or a direct lookup of the 
subject public key against a reregistered value,  or something in between.


I hope that this is non controversial and the WG can adopt it quickly.

Regards
John B.





Begin forwarded message:

*From: *internet-dra...@ietf.org 
*Subject: **New Version Notification for 
draft-campbell-oauth-tls-client-auth-00.txt*

*Date: *October 10, 2016 at 5:44:39 PM GMT-3
*To: *"Brian Campbell" >, "John Bradley" 
>



A new version of I-D, draft-campbell-oauth-tls-client-auth-00.txt
has been successfully submitted by John Bradley and posted to the
IETF repository.

Name:draft-campbell-oauth-tls-client-auth
Revision:00
Title:Mutual X.509 Transport Layer Security (TLS) Authentication for 
OAuth Clients

Document date:2016-10-10
Group:Individual Submission
Pages:5
URL: 
https://www.ietf.org/internet-drafts/draft-campbell-oauth-tls-client-auth-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-campbell-oauth-tls-client-auth/
Htmlized: 
https://tools.ietf.org/html/draft-campbell-oauth-tls-client-auth-00



Abstract:
  This document describes X.509 certificates as OAuth client
  credentials using Transport Layer Security (TLS) mutual
  authentication as a mechanism for client authentication to the
  authorization server's token endpoint.




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 
.


The IETF Secretariat





___
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] Using Referred Token Binding ID for Token Binding of Access Tokens

Re: [OAUTH-WG] Comments on draft-jones-oauth-resource-metadata-00

Re: [OAUTH-WG] OAuth: the ABC attack (the Alice and Bob Collusion attack)

Re: [OAUTH-WG] New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt

Re: [OAUTH-WG] Comments on draft-jones-oauth-resource-metadata-00

Re: [OAUTH-WG] New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt

Re: [OAUTH-WG] New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt

Re: [OAUTH-WG] New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt

Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt

9 matches

Site Navigation

Mail list logo

Footer information