the AS may provide
>>>
>>> https://example.com/apis/
>>> https://example.org/
>>>
>>> or something like that in the audiences.
>>>
>>> A completely new domain should not be trusted blindly.
>>> The resource should at least mak
as being under
>>> the same authority.
>>>
>>> Bearer Token is a Password. It should not be shared among different
>>> authorities.
>>>
>>> Best,
>>>
>>> Nat
>>>
>>> From: OAuth [mailto:oauth-boun...@ietf.or
//example.com/apis/>
>>>>> https://example.org/ <https://example.org/>
>>>>>
>>>>> or something like that in the audiences.
>>>>>
>>>>> A completely new domain should not be trusted blindly.
>>>>>
@ietf.org ] *On
> Behalf Of *George Fletcher
> *Sent:* Wednesday, March 16, 2016 3:15 AM
> *To:* John Bradley ; Brian Campbell <
> bcampb...@pingidentity.com>
> *Cc:*
> *Subject:* Re: [OAUTH-WG] New Version Notification for
> draft-hunt-oauth-bound-config-00.txt
>
&
oauth-boun...@ietf.org] *On Behalf Of *George
Fletcher
*Sent:* Wednesday, March 16, 2016 3:15 AM
*To:* John Bradley ; Brian Campbell
*Cc:*
*Subject:* Re: [OAUTH-WG] New Version Notification for
draft-hunt-oauth-bound-config-00.txt
(..snip..)
I'm not sure passing the full endpoint to the AS
[mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley
Sent: Wednesday, March 16, 2016 2:57 AM
To: Brian Campbell
Cc:
Subject: Re: [OAUTH-WG] New Version Notification for
draft-hunt-oauth-bound-config-00.txt
(..snip..)
The advantage of always sending it in the token request is that it
f.org]*On Behalf Of*George
Fletcher
*Sent:*Wednesday, March 16, 2016 3:15 AM
*To:*John Bradley; Brian
Campbell
*Cc:*
*Subject:*Re: [OAUTH-WG] New Version Notification for
draft-hunt-oauth-bound-config-00.txt
(..snip..)
I'm not sure passing the full endpoint to the AS will help with my
For me the difference between the /token endpoint and an RS endpoint is
semantic. The /token endpoint is part of the AS and a critical part of
the authorization flow.
RS endpoints are under the control of the RS.
Thanks,
George
On 3/16/16 11:30 AM, Phil Hunt (IDM) wrote:
John,
Mis configure
driven Requirement document to start with.
Nat
*From:*OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *John Bradley
*Sent:* Wednesday, March 16, 2016 2:57 AM
*To:* Brian Campbell
*Cc:*
*Subject:* Re: [OAUTH-WG] New Version Notification for
draft-hunt-oauth-bound-config-00.txt
(..snip
should first address it, then get back to the specific protocols.
Best,
Nat Sakimura
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of George Fletcher
Sent: Wednesday, March 16, 2016 6:29 AM
To: John Bradley
Cc:
Subject: Re: [OAUTH-WG] New Version Notification for
draft-hunt
Agreed... so I started a new thread on use cases:) Here is one example.
Assume there is a client that speaks a known OAuth2 protected protocol
(e.g. PortableContacts, or something like Jabber). A user of the client
can enter the endpoint of their RS that speaks the protocol and the
client "dis
*Sent:*Wednesday, March 16, 2016 3:15 AM
*To:*John Bradley; Brian
Campbell
*Cc:*
*Subject:*Re: [OAUTH-WG] New Version Notification for
draft-hunt-oauth-bound-config-00.txt
(..snip..)
I'm not sure passing the full endpoint to the AS will help with my
concerns... The AS could potentially
If the client sends the uri of the resource it intends to send the token to
in the token request the bad guy would get only a token audianced to itself
and not to good RS.
You can't solve the problem of bearer tokens with multiple audiences
leaking. That is a risk inherent in using that sort of
gt;>
>>>> https://example.com/apis/v1/userinfo
>>>> https://example.com/apis/v2/userinfo
>>>> https://example.org/some/api/endpoint
>>>>
>>>> etc., then the AS may provide
>>>>
>>>> https://example.com/apis/
>>>>
[mailto:oauth-boun...@ietf.org <mailto:oauth-boun...@ietf.org>]
>> On Behalf Of George Fletcher
>> Sent: Wednesday, March 16, 2016 3:15 AM
>> To: John Bradley <mailto:ve7...@ve7jtb.com>; Brian
>> Campbell <mailto:bcampb...@pingidentity.com>
>> Cc
Nothing here has anything to do with mix-up. Thats another problem.
Phil
> On Mar 16, 2016, at 16:50, John Bradley wrote:
>
> If you recall in Darmstadt, the group decided that the mix up attack needed
> to be addressed without requiring discovery.
>
> That is why I keep saying the are separ
t;
>> From: OAuth [mailto:oauth-boun...@ietf.org <mailto:oauth-boun...@ietf.org>]
>> On Behalf Of George Fletcher
>> Sent: Wednesday, March 16, 2016 3:15 AM
>> To: John Bradley mailto:ve7...@ve7jtb.com>>; Brian
>> Campbell mailto:bcampb...@pingidentity.com>
-boun...@ietf.org <mailto:oauth-boun...@ietf.org>]
> On Behalf Of George Fletcher
> Sent: Wednesday, March 16, 2016 3:15 AM
> To: John Bradley mailto:ve7...@ve7jtb.com>>; Brian
> Campbell mailto:bcampb...@pingidentity.com>>
> Cc: mailto:oauth@ietf.org>> <ma
] On Behalf Of George Fletcher
Sent: Wednesday, March 16, 2016 3:15 AM
To: John Bradley ; Brian Campbell
Cc:
Subject: Re: [OAUTH-WG] New Version Notification for
draft-hunt-oauth-bound-config-00.txt
(..snip..)
I'm not sure passing the full endpoint to the AS will help with my concern
Right, if the client asks for a token to use at https://evil.rs then the AS
can audience restrict the token to https://evil.rs so that it wouldn't be
usable at https://good.rs.
On Wed, Mar 16, 2016 at 8:46 AM, John Bradley wrote:
> If the client sends the uri of the resource it intends to send
John,
Mis configured token endpoint and resource endpoint is the same client
misconfiguration issue where a client is mis-informed by mistake or mis-deed.
Why do you propose to solve token endpoint in config discovery but feel
resource endpoint must be reverified each time in the core protocol
Your solution seems to require resourceuri = audience.
Bound config avoids trying to require conversion or urls into aud and vice
versa.
Phil
> On Mar 16, 2016, at 07:46, John Bradley wrote:
>
> If the client sends the uri of the resource it intends to send the token to
> in the token requ
If you recall in Darmstadt, the group decided that the mix up attack needed to
be addressed without requiring discovery.
That is why I keep saying the are separate issues.
The proposed fix from the group for the AS confusion was to return a issuer and
client_id from the authorization endpoint,
6, 2016 3:15 AM
*To:*John Bradley mailto:ve7...@ve7jtb.com>>;
Brian Campbell <mailto:bcampb...@pingidentity.com>>
*Cc:*mailto:oauth@ietf.org>> <mailto:oauth@ietf.org>>
*Subject:*Re: [OAUTH-WG] New Version Notification for
draft-hunt-oauth-bound-config-00.txt
(..snip
rom:*OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *George
Fletcher
*Sent:* Wednesday, March 16, 2016 3:15 AM
*To:* John Bradley ; Brian Campbell
*Cc:*
*Subject:* Re: [OAUTH-WG] New Version Notification for
draft-hunt-oauth-bound-config-00.txt
(..snip..)
I'm not sure passing the full
provide the domain as being
>> under the same authority.
>>
>> Bearer Token is a Password. It should not be shared among different
>> authorities.
>>
>> Best,
>>
>> Nat
>>
>> *From:* OAuth [mailto:oauth-boun...@ietf.org ] *On
>> Be
;>>>>>>>>> As to John Bradley’s comments:
>>>>>>>>>>>
>>>>>>>>>>> Re: Discovery is the wrong place to mitigate threats.
>>>>>>>>>>> I’m confused by this. Our mandate wa
s of ways of performing additional kinds of OAuth
discovery, and consider your draft a valuable input to those
discussions.
Best wishes,
-- Mike
*From:*OAuth [mailto:oauth-boun...@ietf.org]*On Behalf
Of*John Bradley
*Sent:*Sunday, March 13, 2016 6:45 PM
*To:*Phil Hunt <mailto:phil.h...@oracle.com
it intends to do and the
>>>>>>>>> service provider can fail that request immediately if necessary. We
>>>>>>>>> don’t have to depend on the developer getting the spec correct to
>>>>>>>>> fail the correct way.
&
ery-01 (with the same title), modulo
>> applying a correction suggested by the working group. To me this
>> suggests that the authorization server metadata definitions in
>> draft-ietf-oauth-discovery (which is now the whole normative
>> content of the draft) are clearly
t; the client tell the service provider what it intends to do and the
>>>>>>>>> service provider can fail that request immediately if necessary. We
>>>>>>>>> don’t have to depend on the developer getting the spec correct to
>>>>>>
x - as the request itself
>>>>>>>> is simple and has only one parameter. Here we are not considered
>>>>>>>> about legitimacy of the client. we’re just concerned with the issue
>>>>>>>> "has the client been correctly informed?”
wishes,
-- Mike
*From:*OAuth [mailto:oauth-boun...@ietf.org]*On Behalf
Of*John Bradley
*Sent:*Sunday, March 13, 2016 6:45 PM
*To:*Phil Hunt <mailto:phil.h...@oracle.com>>
*Cc:*oauth mailto:oauth@ietf.org>>
*Subject:*Re: [OAUTH-WG] New Version Notification for
draft-hunt-oauth-bound-co
t.
-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>] On
Behalf Of Hans Zandbelt
Sent: Monday, March 14, 2016 3:26 PM
To: Phil Hunt (IDM) mailto:phil.h...@oracle.com>>; John
Bradley mailto:ve7...@ve7jtb.com>>
Cc: oauth mailto
gt; service should do validation when possible — this was particularly
>>>>>>>>> true at the Germany meeting when this came up. This is why I prefer
>>>>>>>>> the client tell the service provider what it intends to do and the
>>>&g
kinds of OAuth
discovery, and consider your draft a valuable input to those
discussions.
Best wishes,
-- Mike
*From:*OAuth [mailto:oauth-boun...@ietf.org]*On Behalf Of*John
Bradley
*Sent:*Sunday, March 13, 2016 6:45 PM
*To:*Phil Hunt <mailto:phil.h...@oracle.com>>
*Cc:*oauth mailto:oaut
gt;>>>>>> Phil
>>>>>>>
>>>>>>> @independentid
>>>>>>> www.independentid.com <http://www.independentid.com/>
>>>>>>> <http://www.independentid.com/> <http://www.independentid.com/&g
n merits. I look forward to
the discussions of ways of performing additional kinds of OAuth
discovery, and consider your draft a valuable input to those
discussions.
Best wishes,
-- Mike
*From:*OAuth [mailto:oauth-boun...@ietf.org]*On Behalf Of*John
Bradley
*Sent:*Sunday, March 13, 2016 6:45 PM
to
> your draft and republish, so as to provide a unified way forward
> that is compatible with all known existing OAuth Discovery
> deployments:
> 1.Modify your section 2 “Authorization Server WebFinger Discovery”
> to have the WebFinger request return the issuer identifier for
gt;> Best Regards,
>>>>>>>
>>>>>>> Phil
>>>>>>>
>>>>>>> @independentid
>>>>>>> www.independentid.com <http://www.independentid.com/>
>>>>>>> <http://www.independen
ays of performing additional kinds of OAuth
discovery, and consider your draft a valuable input to those
discussions.
Best wishes,
-- Mike
*From:*OAuth [mailto:oauth-boun...@ietf.org]*On Behalf Of*John
Bradley
*Sent:*Sunday, March 13, 2016 6:45 PM
*To:*Phil Hunt mailto:phil.h...@oracle.com>>
etf.org] On Behalf Of Hans Zandbelt
> Sent: Monday, March 14, 2016 3:26 PM
> To: Phil Hunt (IDM) ; John Bradley <
> ve7...@ve7jtb.com>
> Cc: oauth
> Subject: Re: [OAUTH-WG] New Version Notification for
> draft-hunt-oauth-bound-config-00.txt
>
> On 3/14/16 10:17 PM, Phil Hu
Best wishes,
-- Mike
*From:*OAuth [mailto:oauth-boun...@ietf.org]*On Behalf Of*John Bradley
*Sent:*Sunday, March 13, 2016 6:45 PM
*To:*Phil Hunt mailto:phil.h...@oracle.com>>
*Cc:*oauth mailto:oauth@ietf.org>>
*Subject:*Re: [OAUTH-WG
out that there appears to be complete
>>>>>> agreement on what the authorization server metadata format should be,
>>>>>> which is great! I’ll note that Section 3 of
>>>>>> draft-hunt-oauth-bound-config-00 titled “Authorization Server Metadata”
>
ive proposal includes them verbatim.
>>>>>
>>>>> Reading your draft, the problem I have with it is that you are returning
>>>>> the AS metadata only as a WebFinger response, rather than as an
>>>>> https-protected resource published by
Cc: oauth
Subject: Re: [OAUTH-WG] New Version Notification for
draft-hunt-oauth-bound-config-00.txt
On 3/14/16 10:17 PM, Phil Hunt (IDM) wrote:
> On Mar 14, 2016, at 14:13, John Bradley <mailto:ve7...@ve7jtb.com>> wrote:
>> Any client that has the resource and issuer h
Config” column in the
>>>> table) and OAuth 2.0 libraries such as Microsoft’s “ADAL” library, which
>>>> uses the metadata path for client configuration. Without having ASs
>>>> provide the metadata as an https-protected resource, implementations such
>&g
On 3/14/16 10:17 PM, Phil Hunt (IDM) wrote:
On Mar 14, 2016, at 14:13, John Bradley mailto:ve7...@ve7jtb.com>> wrote:
Any client that has the resource and issuer hard coded probably
doesn’t need discovery.
We agree
Yet any client that has hard coded a resource and 2 issuers doesn't need
dis
ion 2 “Authorization Server WebFinger Discovery”
>>> to have the WebFinger request return the issuer identifier for the AS as
>>> the “WebFinger “rel” value, rather than returning the metadata values by
>>> value as the “properties” value.
>>> 2. Refer
paring your draft down to only the new
>> things that it proposes, enabling them to be more clearly understood and
>> evaluated on their own merits. I look forward to the discussions of ways of
>> performing additional kinds of OAuth discovery, and consider your draft a
>>
> Best wishes,
> -- Mike
>
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley
> Sent: Sunday, March 13, 2016 6:45 PM
> To: Phil Hunt
&
decision bases upon
OpenID Certification.
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones
Sent: Sunday, March 13, 2016 10:29 PM
To: Phil Hunt
Cc: oauth
Subject: Re: [OAUTH-WG] New Version Notification for
draft-hunt-oauth-bound-config-00.txt
Thanks for posting this, Phil. It
PM
To: Phil Hunt
Cc: oauth
Subject: Re: [OAUTH-WG] New Version Notification for
draft-hunt-oauth-bound-config-00.txt
As I have told Phil off list.
Discovery is the wrong place to try and provide security against man in the
middle attacks on the RS.
This requires the client to know what the
As I have told Phil off list.
Discovery is the wrong place to try and provide security against man in the
middle attacks on the RS.
This requires the client to know what the RS URI is before retrieving the
information on the AS Configuration.
The proposal Mike and I have been working on requ
This draft is a proposed alternate proposal for draft-ietf-oauth-discovery. As
such, it contains the same registry for OAuth Config Metadata as the authors
believe that both solutions are not required, or depending on WG discussion
they will be merged. The intent is to provide a simple complete
55 matches
Mail list logo
