Re: [OAUTH-WG] Multiple authorization servers for one resource server

2016-03-12 Thread Justin Richer 
Agree with Phil, an additional header is a bad idea. It's not only yet 
another thing that can be attacked, it's another thing that can get out 
of sync by the client. Always assume OAuth clients are the dumbest parts 
of the system.


 -- Justin

On 3/12/2016 2:36 PM, Phil Hunt (IDM) wrote:
Right now we are discussing mis-configured clients that have been 
convinced to use a token or rs endpoint that has been mitm. Adding a 
new parameter increases attack surface because the rs is now ignoring 
the token abd believing the header which may have been inserted.


Phil

On Mar 12, 2016, at 11:29, Jim Willeke > wrote:



Would a header be a concern if TLS was used for transportation?

--
-jim
Jim Willeke

On Sat, Mar 12, 2016 at 10:03 AM, Phil Hunt (IDM) 
> wrote:


A header might open another attack vector. Better to parse the
jwt and look for the issuer assuming the jwt validates.

Phil

On Mar 12, 2016, at 09:02, Jim Willeke > wrote:


Why not register JWT as anaccess token type


and then the the Issuer is implied?

--
-jim
Jim Willeke

On Sat, Mar 12, 2016 at 8:32 AM, Mike Schwartz > wrote:

Kawasaki-san,

This is a really good question: how to know the issuer of a
bearer token. Is there a header that could be added to
specify the issuer, or other important metadata?

- Mike


-
Michael Schwartz
Gluu
Founder / CEO
m...@gluu.org 

___
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



___
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] Multiple authorization servers for one resource server

2016-03-12 Thread Justin Richer 
What we've done in deployments is to combine JWT and introspection. You 
have all of your servers issue signed JWTs that include the "iss" 
(issuer) in the body, signed with the key of the AS. The tokens also 
include a random "jti" field. The RS submits the token to the 
introspection endpoint of the server identified in "iss", but only after 
validating the signature and other basic bits of information. If the 
introspection call comes back positive (and with the right scope, 
client, and resource owner information), the resource is served.


 -- Justin

On 3/11/2016 10:02 PM, Takahiko Kawasaki wrote:

Hello,

I have a question.

If there exist multiple authorization servers that can issue access 
tokens for one resource server, when the resource server receives an 
access token from a client application, as the first step, the 
resource server has to determine which authorization server to use for 
access token introspection.


Is there any standard way to determine which authorization server to use?

There may be several ways, for example:

(1) Embed information about the access token issuer in the access token.
(2) Add a request parameter to identify the access token issuer.
(3) Separate protected resource endpoints for each authorization server.

If there is a standard way, I'd like to know it.

Best Regards,
Takahiko Kawasaki



___
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] Working Group Last Call on OAuth 2.0 Discovery

2016-03-12 Thread Thomas Broyer 
On Sat, Mar 12, 2016 at 6:01 PM Anthony Nadalin 
wrote:

> This is not discovery, its simply metadata, […], I don’t understand the
> rush to get this document out when we already know it’s incomplete
>
+1
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Multiple authorization servers for one resource server

2016-03-12 Thread Phil Hunt (IDM) 
Right now we are discussing mis-configured clients that have been convinced to 
use a token or rs endpoint that has been mitm. Adding a new parameter increases 
attack surface because the rs is now ignoring the token abd believing the 
header which may have been inserted. 

Phil

> On Mar 12, 2016, at 11:29, Jim Willeke  wrote:
> 
> Would a header be a concern if TLS was used for transportation?
> 
> --
> -jim
> Jim Willeke
> 
>> On Sat, Mar 12, 2016 at 10:03 AM, Phil Hunt (IDM)  
>> wrote:
>> A header might open another attack vector. Better to parse the jwt and look 
>> for the issuer assuming the jwt validates. 
>> 
>> Phil
>> 
>>> On Mar 12, 2016, at 09:02, Jim Willeke  wrote:
>>> 
>>> Why not register JWT as an access token type and then the the Issuer is 
>>> implied?
>>> 
>>> --
>>> -jim
>>> Jim Willeke
>>> 
 On Sat, Mar 12, 2016 at 8:32 AM, Mike Schwartz  wrote:
 Kawasaki-san,
 
 This is a really good question: how to know the issuer of a bearer token. 
 Is there a header that could be added to specify the issuer, or other 
 important metadata?
 
 - Mike
 
 
 -
 Michael Schwartz
 Gluu
 Founder / CEO
 m...@gluu.org
 
 ___
 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
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Multiple authorization servers for one resource server

2016-03-12 Thread Jim Willeke 
Would a header be a concern if TLS was used for transportation?

--
-jim
Jim Willeke

On Sat, Mar 12, 2016 at 10:03 AM, Phil Hunt (IDM) 
wrote:

> A header might open another attack vector. Better to parse the jwt and
> look for the issuer assuming the jwt validates.
>
> Phil
>
> On Mar 12, 2016, at 09:02, Jim Willeke  wrote:
>
> Why not register JWT as an access token type
> 
> and then the the Issuer is implied?
>
> --
> -jim
> Jim Willeke
>
> On Sat, Mar 12, 2016 at 8:32 AM, Mike Schwartz  wrote:
>
>> Kawasaki-san,
>>
>> This is a really good question: how to know the issuer of a bearer token.
>> Is there a header that could be added to specify the issuer, or other
>> important metadata?
>>
>> - Mike
>>
>>
>> -
>> Michael Schwartz
>> Gluu
>> Founder / CEO
>> m...@gluu.org
>>
>> ___
>> 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] Multiple authorization servers for one resource server

2016-03-12 Thread Phil Hunt (IDM) 
A header might open another attack vector. Better to parse the jwt and look for 
the issuer assuming the jwt validates. 

Phil

> On Mar 12, 2016, at 09:02, Jim Willeke  wrote:
> 
> Why not register JWT as an access token type and then the the Issuer is 
> implied?
> 
> --
> -jim
> Jim Willeke
> 
>> On Sat, Mar 12, 2016 at 8:32 AM, Mike Schwartz  wrote:
>> Kawasaki-san,
>> 
>> This is a really good question: how to know the issuer of a bearer token. Is 
>> there a header that could be added to specify the issuer, or other important 
>> metadata?
>> 
>> - Mike
>> 
>> 
>> -
>> Michael Schwartz
>> Gluu
>> Founder / CEO
>> m...@gluu.org
>> 
>> ___
>> 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] Working Group Last Call on OAuth 2.0 Discovery

2016-03-12 Thread Phil Hunt (IDM) 
I will put that forward in an alternate draft. 

Phil

> On Mar 12, 2016, at 08:28, Mike Jones  wrote:
> 
> The AS metadata format is a necessary part of discovery.  No, it doesn’t 
> accomplish every possible aspect of discovery – nor was it ever intended to.  
> I’ve consistently encouraged Phil and others to write down additional aspects 
> of discovery in specifications that build upon this one so that the working 
> group and implementers can evaluate them.
>  
> Since we’re chartered to do discovery and this is part of discovery, no 
> rechartering is needed either for the current specification or for new 
> specifications performing additional discovery tasks.
>  
>   -- Mike
>  
> From: Anthony Nadalin 
> Sent: Saturday, March 12, 2016 8:20 AM
> To: Mike Jones ; Brian Campbell 
> ; John Bradley 
> Cc: oauth 
> Subject: RE: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
>  
> We agreed upon a discovery specification that the WG would work on, we did 
> not agree upon what this has turned out to actually be, so at the minimum the 
> chairs should call for adoption of a Authorization Server Metadata 
> specification and we can continue to work on a Discovery specification
>  
> From: Mike Jones 
> Sent: Saturday, March 12, 2016 8:06 AM
> To: Anthony Nadalin ; Brian Campbell 
> ; John Bradley 
> Cc: oauth 
> Subject: RE: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
>  
> The draft enables easy configuration of OAuth clients with an AS.  For 
> instance, the Microsoft “ADAL” OAuth client software uses AS metadata in this 
> format as an input at client configuration time.
>  
> As a side benefit, having this standard AS metadata format and returning the 
> issuer URL per the Mix-Up Mitigation draft will also enable clients to 
> validate that they are using a consistent set of AS endpoints and 
> information.  But even without the mitigation benefits, the client 
> configuration benefit is the primary reason for the specification.
>  
>   -- Mike
>  
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Anthony Nadalin
> Sent: Friday, March 11, 2016 3:25 PM
> To: Brian Campbell ; John Bradley 
> 
> Cc: oauth 
> Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
>  
> Disagree, what purpose is this activity solving then, it was being pushed as 
> what was need to solve the Mix-up, but that is not true. So now you are 
> suggesting a change in scope and not dealing with discovery.
>  
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
> Sent: Friday, March 11, 2016 3:11 PM
> To: John Bradley 
> Cc: oauth 
> Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
>  
> I tend to agree with John that addressing the concerns Phil raises should be 
> part of (extension to) the core protocol.  And that those kinds of concerns 
> don't manifest in the way OAuth is typically deployed now. 
> 
> The hopefully soon to be named "OAuth 2.0 Authorization Server Metadata" 
> should keep it's scope to the publishing of authorization server metadata. 
> The act of doing discovery is beyond its scope and so is trying to prevent a 
> client from presenting a token to someplace it shouldn't.
> 
>  
> On Fri, Mar 11, 2016 at 9:08 AM, John Bradley  wrote:
> Inline
> On Mar 11, 2016, at 12:13 PM, Phil Hunt (IDM)  wrote:
>  
> John
>  
> In many case all the AS has to check is the domain name component to check 
> for mitm. 
>  
> POP and the other solns are dramatically more complex than a simple check. 
>  
> I was proposing ding that check at the authorization endpoint or token 
> endpoint as part of AT issuance. 
>  
> It is up to the AS how much of the path to validate and or put in the aud or 
> dst. 
>  
>  
>  
> I see it as part of the discovery(bad name aside) problem because we 
> discussed that if a client finds app.example.com how do we ensure it gets a 
> complete set of oauth endpoints as a valid set of endpoints--that a hacker 
> has not inserted one of their own endpoints. The most important endpoint to 
> get right is ensuring the resource server (and optionally the path) is the 
> correct one. We can't really define resource discovery but we can validate it 
> to some degree. 
>  
> I think it is part of core protocol security and should/must not require 
> discovery. 
>  
> What is app.example.com ? 
>  
> If it is the resource then the client would be preconfigured for it’s AS out 
> of band or optionally would do discovery on the issuer uri that you admit 
> needs to be

Re: [OAUTH-WG] Multiple authorization servers for one resource server

2016-03-12 Thread Jim Willeke 
Why not register JWT as an access token type

and then the the Issuer is implied?

--
-jim
Jim Willeke

On Sat, Mar 12, 2016 at 8:32 AM, Mike Schwartz  wrote:

> Kawasaki-san,
>
> This is a really good question: how to know the issuer of a bearer token.
> Is there a header that could be added to specify the issuer, or other
> important metadata?
>
> - Mike
>
>
> -
> Michael Schwartz
> Gluu
> Founder / CEO
> m...@gluu.org
>
> ___
> 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] Working Group Last Call on OAuth 2.0 Discovery

2016-03-12 Thread Anthony Nadalin 
This is not discovery, its simply metadata, it’s unclear if this is all the 
metadata that is needed  because discovery has not been fully thought out as 
apparent from all the exchanges that have been going on, I don’t understand the 
rush to get this document out when we already know it’s incomplete

There are still documents from Nat, and I believe there will be one from Phil 
and maybe others.

From: Mike Jones
Sent: Saturday, March 12, 2016 8:29 AM
To: Anthony Nadalin ; Brian Campbell 
; John Bradley 
Cc: oauth 
Subject: RE: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

The AS metadata format is a necessary part of discovery.  No, it doesn’t 
accomplish every possible aspect of discovery – nor was it ever intended to.  
I’ve consistently encouraged Phil and others to write down additional aspects 
of discovery in specifications that build upon this one so that the working 
group and implementers can evaluate them.

Since we’re chartered to do discovery and this is part of discovery, no 
rechartering is needed either for the current specification or for new 
specifications performing additional discovery tasks.

  -- Mike

From: Anthony Nadalin
Sent: Saturday, March 12, 2016 8:20 AM
To: Mike Jones 
>; Brian 
Campbell >; John 
Bradley >
Cc: oauth >
Subject: RE: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

We agreed upon a discovery specification that the WG would work on, we did not 
agree upon what this has turned out to actually be, so at the minimum the 
chairs should call for adoption of a Authorization Server Metadata 
specification and we can continue to work on a Discovery specification

From: Mike Jones
Sent: Saturday, March 12, 2016 8:06 AM
To: Anthony Nadalin >; 
Brian Campbell >; 
John Bradley >
Cc: oauth >
Subject: RE: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

The draft enables easy configuration of OAuth clients with an AS.  For 
instance, the Microsoft “ADAL” OAuth client software uses AS metadata in this 
format as an input at client configuration time.

As a side benefit, having this standard AS metadata format and returning the 
issuer URL per the Mix-Up Mitigation draft will also enable clients to validate 
that they are using a consistent set of AS endpoints and information.  But even 
without the mitigation benefits, the client configuration benefit is the 
primary reason for the specification.

  -- Mike

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Anthony Nadalin
Sent: Friday, March 11, 2016 3:25 PM
To: Brian Campbell 
>; John Bradley 
>
Cc: oauth >
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

Disagree, what purpose is this activity solving then, it was being pushed as 
what was need to solve the Mix-up, but that is not true. So now you are 
suggesting a change in scope and not dealing with discovery.

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Friday, March 11, 2016 3:11 PM
To: John Bradley >
Cc: oauth >
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

I tend to agree with John that addressing the concerns Phil raises should be 
part of (extension to) the core protocol.  And that those kinds of concerns 
don't manifest in the way OAuth is typically deployed now.

The hopefully soon to be named "OAuth 2.0 Authorization Server Metadata" should 
keep it's scope to the publishing of authorization server metadata. The act of 
doing discovery is beyond its scope and so is trying to prevent a client from 
presenting a token to someplace it shouldn't.

On Fri, Mar 11, 2016 at 9:08 AM, John Bradley 
> wrote:
Inline
On Mar 11, 2016, at 12:13 PM, Phil Hunt (IDM) 
> wrote:

John

In many case all the AS has to check is the domain name component to check for 
mitm.

POP and the other solns are dramatically more complex than a simple check.

I was proposing ding that check at the authorization endpoint or token endpoint 
as part of AT issuance.

It is up to the AS how much of the path to validate and or put in the aud or 
dst.



I see it as part of

Re: [OAUTH-WG] Multiple authorization servers for one resource server

2016-03-12 Thread Mike Schwartz 

Kawasaki-san,

This is a really good question: how to know the issuer of a bearer 
token. Is there a header that could be added to specify the issuer, or 
other important metadata?


- Mike


-
Michael Schwartz
Gluu
Founder / CEO
m...@gluu.org

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

Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

2016-03-12 Thread Mike Jones 
The AS metadata format is a necessary part of discovery.  No, it doesn’t 
accomplish every possible aspect of discovery – nor was it ever intended to.  
I’ve consistently encouraged Phil and others to write down additional aspects 
of discovery in specifications that build upon this one so that the working 
group and implementers can evaluate them.

Since we’re chartered to do discovery and this is part of discovery, no 
rechartering is needed either for the current specification or for new 
specifications performing additional discovery tasks.

  -- Mike

From: Anthony Nadalin
Sent: Saturday, March 12, 2016 8:20 AM
To: Mike Jones ; Brian Campbell 
; John Bradley 
Cc: oauth 
Subject: RE: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

We agreed upon a discovery specification that the WG would work on, we did not 
agree upon what this has turned out to actually be, so at the minimum the 
chairs should call for adoption of a Authorization Server Metadata 
specification and we can continue to work on a Discovery specification

From: Mike Jones
Sent: Saturday, March 12, 2016 8:06 AM
To: Anthony Nadalin >; 
Brian Campbell >; 
John Bradley >
Cc: oauth >
Subject: RE: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

The draft enables easy configuration of OAuth clients with an AS.  For 
instance, the Microsoft “ADAL” OAuth client software uses AS metadata in this 
format as an input at client configuration time.

As a side benefit, having this standard AS metadata format and returning the 
issuer URL per the Mix-Up Mitigation draft will also enable clients to validate 
that they are using a consistent set of AS endpoints and information.  But even 
without the mitigation benefits, the client configuration benefit is the 
primary reason for the specification.

  -- Mike

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Anthony Nadalin
Sent: Friday, March 11, 2016 3:25 PM
To: Brian Campbell 
>; John Bradley 
>
Cc: oauth >
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

Disagree, what purpose is this activity solving then, it was being pushed as 
what was need to solve the Mix-up, but that is not true. So now you are 
suggesting a change in scope and not dealing with discovery.

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Friday, March 11, 2016 3:11 PM
To: John Bradley >
Cc: oauth >
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

I tend to agree with John that addressing the concerns Phil raises should be 
part of (extension to) the core protocol.  And that those kinds of concerns 
don't manifest in the way OAuth is typically deployed now.

The hopefully soon to be named "OAuth 2.0 Authorization Server Metadata" should 
keep it's scope to the publishing of authorization server metadata. The act of 
doing discovery is beyond its scope and so is trying to prevent a client from 
presenting a token to someplace it shouldn't.

On Fri, Mar 11, 2016 at 9:08 AM, John Bradley 
> wrote:
Inline
On Mar 11, 2016, at 12:13 PM, Phil Hunt (IDM) 
> wrote:

John

In many case all the AS has to check is the domain name component to check for 
mitm.

POP and the other solns are dramatically more complex than a simple check.

I was proposing ding that check at the authorization endpoint or token endpoint 
as part of AT issuance.

It is up to the AS how much of the path to validate and or put in the aud or 
dst.



I see it as part of the discovery(bad name aside) problem because we discussed 
that if a client finds 
app.example.com
 how do we ensure it gets a complete set of oauth endpoints as a valid set of 
endpoints--that a hacker has not inserted one of their own endpoints. The most 
important endpoint to get right is ensuring the resource server (and optionally 
the path) is the correct one. We can't really define resource discovery but we 
can validate it to some degree.

I think it is part of core protocol security and should/must not require 
discovery.

What is

Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

2016-03-12 Thread Anthony Nadalin 
We agreed upon a discovery specification that the WG would work on, we did not 
agree upon what this has turned out to actually be, so at the minimum the 
chairs should call for adoption of a Authorization Server Metadata 
specification and we can continue to work on a Discovery specification

From: Mike Jones
Sent: Saturday, March 12, 2016 8:06 AM
To: Anthony Nadalin ; Brian Campbell 
; John Bradley 
Cc: oauth 
Subject: RE: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

The draft enables easy configuration of OAuth clients with an AS.  For 
instance, the Microsoft “ADAL” OAuth client software uses AS metadata in this 
format as an input at client configuration time.

As a side benefit, having this standard AS metadata format and returning the 
issuer URL per the Mix-Up Mitigation draft will also enable clients to validate 
that they are using a consistent set of AS endpoints and information.  But even 
without the mitigation benefits, the client configuration benefit is the 
primary reason for the specification.

  -- Mike

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Anthony Nadalin
Sent: Friday, March 11, 2016 3:25 PM
To: Brian Campbell 
>; John Bradley 
>
Cc: oauth >
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

Disagree, what purpose is this activity solving then, it was being pushed as 
what was need to solve the Mix-up, but that is not true. So now you are 
suggesting a change in scope and not dealing with discovery.

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Friday, March 11, 2016 3:11 PM
To: John Bradley >
Cc: oauth >
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

I tend to agree with John that addressing the concerns Phil raises should be 
part of (extension to) the core protocol.  And that those kinds of concerns 
don't manifest in the way OAuth is typically deployed now.

The hopefully soon to be named "OAuth 2.0 Authorization Server Metadata" should 
keep it's scope to the publishing of authorization server metadata. The act of 
doing discovery is beyond its scope and so is trying to prevent a client from 
presenting a token to someplace it shouldn't.

On Fri, Mar 11, 2016 at 9:08 AM, John Bradley 
> wrote:
Inline
On Mar 11, 2016, at 12:13 PM, Phil Hunt (IDM) 
> wrote:

John

In many case all the AS has to check is the domain name component to check for 
mitm.

POP and the other solns are dramatically more complex than a simple check.

I was proposing ding that check at the authorization endpoint or token endpoint 
as part of AT issuance.

It is up to the AS how much of the path to validate and or put in the aud or 
dst.



I see it as part of the discovery(bad name aside) problem because we discussed 
that if a client finds 
app.example.com
 how do we ensure it gets a complete set of oauth endpoints as a valid set of 
endpoints--that a hacker has not inserted one of their own endpoints. The most 
important endpoint to get right is ensuring the resource server (and optionally 
the path) is the correct one. We can't really define resource discovery but we 
can validate it to some degree.

I think it is part of core protocol security and should/must not require 
discovery.

What is 
app.example.com
 ?

If it is the resource then the client would be preconfigured for it’s AS out of 
band or optionally would do discovery on the issuer uri that you admit needs to 
be configured out of band some way (note discovery is optional)

In the AS meta-data draft it would do a get on a well known file that would 
have configuration for the AS, but not the RS, though some API may optionally 
list a API endpoint like connect has.

The client then makes a authorization request (after registering out of band or 
dynamically).
As part of the authorization request for implicit it could provide the aud/dst 
that it wants the token for.
If that is not sent then the aud/dst are implicit in the scopes.

The client gets back a AT with a list of scopes granted, aud/dst allowed and

Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

2016-03-12 Thread Mike Jones 
The draft enables easy configuration of OAuth clients with an AS.  For 
instance, the Microsoft “ADAL” OAuth client software uses AS metadata in this 
format as an input at client configuration time.

As a side benefit, having this standard AS metadata format and returning the 
issuer URL per the Mix-Up Mitigation draft will also enable clients to validate 
that they are using a consistent set of AS endpoints and information.  But even 
without the mitigation benefits, the client configuration benefit is the 
primary reason for the specification.

  -- Mike

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Anthony Nadalin
Sent: Friday, March 11, 2016 3:25 PM
To: Brian Campbell ; John Bradley 

Cc: oauth 
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

Disagree, what purpose is this activity solving then, it was being pushed as 
what was need to solve the Mix-up, but that is not true. So now you are 
suggesting a change in scope and not dealing with discovery.

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Friday, March 11, 2016 3:11 PM
To: John Bradley >
Cc: oauth >
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

I tend to agree with John that addressing the concerns Phil raises should be 
part of (extension to) the core protocol.  And that those kinds of concerns 
don't manifest in the way OAuth is typically deployed now.

The hopefully soon to be named "OAuth 2.0 Authorization Server Metadata" should 
keep it's scope to the publishing of authorization server metadata. The act of 
doing discovery is beyond its scope and so is trying to prevent a client from 
presenting a token to someplace it shouldn't.

On Fri, Mar 11, 2016 at 9:08 AM, John Bradley 
> wrote:
Inline
On Mar 11, 2016, at 12:13 PM, Phil Hunt (IDM) 
> wrote:

John

In many case all the AS has to check is the domain name component to check for 
mitm.

POP and the other solns are dramatically more complex than a simple check.

I was proposing ding that check at the authorization endpoint or token endpoint 
as part of AT issuance.

It is up to the AS how much of the path to validate and or put in the aud or 
dst.



I see it as part of the discovery(bad name aside) problem because we discussed 
that if a client finds 
app.example.com
 how do we ensure it gets a complete set of oauth endpoints as a valid set of 
endpoints--that a hacker has not inserted one of their own endpoints. The most 
important endpoint to get right is ensuring the resource server (and optionally 
the path) is the correct one. We can't really define resource discovery but we 
can validate it to some degree.

I think it is part of core protocol security and should/must not require 
discovery.

What is 
app.example.com
 ?

If it is the resource then the client would be preconfigured for it’s AS out of 
band or optionally would do discovery on the issuer uri that you admit needs to 
be configured out of band some way (note discovery is optional)

In the AS meta-data draft it would do a get on a well known file that would 
have configuration for the AS, but not the RS, though some API may optionally 
list a API endpoint like connect has.

The client then makes a authorization request (after registering out of band or 
dynamically).
As part of the authorization request for implicit it could provide the aud/dst 
that it wants the token for.
If that is not sent then the aud/dst are implicit in the scopes.

The client gets back a AT with a list of scopes granted, aud/dst allowed and 
time to live for the token (one extra thing returned)

This doesn’t require any discovery (yes there is a optional AS meta-data 
discovery but not required)

I prefer to fix the RS man in the middle issue as part of the protocol and not 
part of discovery that should remain optional.

I honestly don’t quite know how the client learns about this bad RS and starts 
talking to it, so this may be a solution to a problem that doesn’t yet exist.   
The one place this is posable is if the registration for the client is 
compromised.  However we are discussing other mitigations for that that also 
explicitly do not require discovery.

John B.


I am not stuck