Re: [OAUTH-WG] Call for adoption for "Distributed OAuth"

[Torsten Lodderstedt]

+1

> Am 20.07.2018 um 08:21 schrieb n-sakimura :
> 
> And if it were not obvious, YES J
>  
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Dick Hardt
> Sent: Friday, July 20, 2018 6:12 AM
> To: Rifaat Shekh-Yusef 
> Cc: oauth 
> Subject: Re: [OAUTH-WG] Call for adoption for "Distributed OAuth"
>  
> I'm supportive. :)
>  
> On Thu, Jul 19, 2018 at 4:05 PM, Rifaat Shekh-Yusef  
> wrote:
> Hi all,
>  
> This is the call for adoption of the 'Distributed OAuth' document
> following the positive call for adoption at the Montreal IETF meeting.
>  
> Here is the document:
> https://datatracker.ietf.org/doc/draft-hardt-oauth-distributed/
>  
> Please let us know by August 2nd whether you accept / object to the
> adoption of this document as a starting point for work in the OAuth
> working group.
>  
> Regards,
> Hannes & Rifaat
>  
> 
> ___
> 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


smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for adoption for "Resource Indicators for OAuth 2.0"

[Torsten Lodderstedt]

I support adoption of this document.

I would like to point out (again) a single resource is not sufficient for most 
use cases I implemented in the last couple if years. I‘m advocating for 
enhancing the draft to support multiple resources and a clear definition of the 
relationship between resource(s) and scope.

> Am 20.07.2018 um 08:20 schrieb n-sakimura :
> 
> +1
>  
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
> Sent: Friday, July 20, 2018 7:42 AM
> To: Rifaat Shekh-Yusef 
> Cc: oauth 
> Subject: Re: [OAUTH-WG] Call for adoption for "Resource Indicators for OAuth 
> 2.0"
>  
> I support adoption of this document.
>  
> On Thu, Jul 19, 2018 at 4:01 PM, Rifaat Shekh-Yusef  
> wrote:
> Hi all,
> 
> This is the call for adoption of the 'Resource Indicators for OAuth 2.0' 
> document
> following the positive call for adoption at the Montreal IETF meeting.
> 
> Here is the document:
> https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-02
> 
> Please let us know by August 2nd whether you accept / object to the
> adoption of this document as a starting point for work in the OAuth
> working group.
> 
> Regards,
> Rifaat
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> 
>  
> 
> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
> material for the sole use of the intended recipient(s). Any review, use, 
> distribution or disclosure by others is strictly prohibited..  If you have 
> received this communication in error, please notify the sender immediately by 
> e-mail and delete the message and any file attachments from your computer. 
> Thank you.
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for adoption for "Resource Indicators for OAuth 2.0"

[Filip Skokan]

Hi Torsten,

> Multiple "resource" parameters may be used to indicate that the issued
token is intended to be used at multiple resource servers.

That's already in. Furthermore what about logical names for target
services? Like was added in -03 of token exchange?

Best,
*Filip Skokan*


On Fri, Jul 20, 2018 at 9:33 AM Torsten Lodderstedt 
wrote:

> I support adoption of this document.
>
> I would like to point out (again) a single resource is not sufficient for
> most use cases I implemented in the last couple if years. I‘m advocating
> for enhancing the draft to support multiple resources and a clear
> definition of the relationship between resource(s) and scope.
>
> Am 20.07.2018 um 08:20 schrieb n-sakimura :
>
> +1
>
>
>
> *From:* OAuth [mailto:oauth-boun...@ietf.org ] *On
> Behalf Of *Brian Campbell
> *Sent:* Friday, July 20, 2018 7:42 AM
> *To:* Rifaat Shekh-Yusef 
> *Cc:* oauth 
> *Subject:* Re: [OAUTH-WG] Call for adoption for "Resource Indicators for
> OAuth 2.0"
>
>
>
> I support adoption of this document.
>
>
>
> On Thu, Jul 19, 2018 at 4:01 PM, Rifaat Shekh-Yusef 
> wrote:
>
> Hi all,
>
> This is the call for adoption of the 'Resource Indicators for OAuth 2.0'
> document
> following the positive call for adoption at the Montreal IETF meeting.
>
> Here is the document:
> https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-02
>
> Please let us know by August 2nd whether you accept / object to the
> adoption of this document as a starting point for work in the OAuth
> working group.
>
> Regards,
> Rifaat
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited...
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*
>
> ___
> 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] updated Distributed OAuth ID

[n-sakimura]

Hi David,

Thanks for the comment, and sorry for the delay in my reply.

Doing it with Web Linking [RFC8288]  has several advantages.


  1.  It is standard based ☺ It is just a matter of registering link relations 
to the IANA Link Relation Type Registry, and it is quite widely used.
  2.  No or very little coding needed: Other than adding some HTTP server 
configuration, the rest stays the same as RFC6750.
  3.  Standard interface: this kind of metadata is applicable not only for 
letting the client find the appropriate authorization server but for other 
metadata as well. Also, other endpoints as long as it is supporting the direct 
communication with the client, can provide relevant metadata with it without 
going through the client authorization.

I did not quite follow why CORS is relevant here. We are just talking about the 
client to server communication, and there are no embedded resources in the 
response. Could you kindly elaborate a little, please?

For the second point, since it was discussed in the WG meeting yesterday, I 
will defer to that discussion.

Best,

Nat Sakimura


From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of David Waite
Sent: Thursday, July 19, 2018 4:55 PM
To: Dick Hardt 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] updated Distributed OAuth ID

Four comments.

First: What is the rationale for including the parameters as Link headers 
rather than part of the WWW-Authenticate challenge, e.g.:

WWW-Authenticate: Bearer realm="example_realm",
 scope="example_scope",
 error=“invalid_token",
resource_uri="https://api.example.com/resource";,

oauth_server_metadata_uris="https://as.example.com/.well-known/oauth-authorization-server
 https://different-as.example.com/.well-known/oauth-authorization-server";

My understanding is that the RFC6750 auth-params are extensible (but not 
currently part of any managed registry.)

One reason to go with this vs Link headers is CORS policy - exposing Link 
headers to a remote client must be done all or nothing as part of the CORS 
policy, and can’t be limited by the kind of link.

Second: (retaining link format) Is there a reason the metadata location is 
specified the way it is? It seems like

; 
rel=“oauth_server_metadata_uri"

should be

; rel=“oauth_issuer"

OAuth defines the location of metadata under the .well-known endpoint as a 
MUST. An extension of OAuth may choose from at least three different methods 
for handling extensions beyond this:
1. Add additional keys to the oauth-authorization-server metadata
2. Add additional resources to .well-known for clients to supporting their 
extensions to attempt to resolve, treating ‘regular’ OAuth as a fallback.
3. Define their own parameter, such as rel=“specialauth_issuer”, potentially 
using a different mechanism for specifying metadata

Given all this, it seems appropriate to only support specifying of 
metadata-supplying issuers, not metadata uris.

Third: I have doubts of the usefulness of resource_uri in parallel to both the 
client requested URI and the Authorization “realm” parameter.

As currently defined, the client would be the one enforcing (or possibly 
ignoring) static policy around resource URIs - that a resource URI is arbitrary 
except in that it must match the host (and scheme/port?) of the requested URI. 
The information on the requested URI by the client is not shared between the 
client and AS for it to do its own policy verification. It would seem better to 
send the client origin to the AS for it to do (potential) policy verification, 
rather than relying on clients to implement it for them based on static spec 
policy.

The name “resource URI” is also confusing, as I would expect it to be the URI 
that was requested by the client. The purpose of this parameter is a bit 
confusing, as it is only defined as “An OAuth 2.0 Resource Endpoint specified 
in [RFC6750] section 3.2 - where the term doesn’t appear in 6750 and there does 
not appear to be a section 3.2 ;-)

It seems that:
a. If the resource_uri is a direct match for the URI requested for the client, 
it is redundant and should be dropped
(If the resource URI is *not* a direct match with the URI of the resource 
requested by the client, it might need a better name).
b. If the resource URI is meant to provide a certain arbitrary grouping for 
applying tokens within the origin of the resource server, what is its value 
over the preexisting “ realm” parameter?
c. If the resource URI is meant to provide a way for an AS to allow resources 
to be independent, identified entities on a single origin - I’m unsure how a 
client would understand it is meant to treat these resource URIs as independent 
entities (e.g. be sure not to send bearer tokens minted for resource /entity1 
to /entity2, or for that matter prevent /entity1 from requesting tokens for 
/entity2).

Admi

Re: [OAUTH-WG] Call for adoption of "JWT Response for OAuth Token Introspection"

[Anthony Nadalin]

I’m concerned over the security implications of a client being able to 
introspect a token, for bearer tokens this can be very problematic, so unless 
the issues with possible token theft can be addressed I don’t support this as a 
WG draft

From: OAuth  On Behalf Of Rifaat Shekh-Yusef
Sent: Thursday, July 19, 2018 10:44 AM
To: oauth 
Subject: [OAUTH-WG] Call for adoption of "JWT Response for OAuth Token 
Introspection"

Hi all,

This is the call for adoption of the 'JWT Response for OAuth Token 
Introspection' document following the presentation by Torsten at the Montreal 
IETF meeting where we didn't have a chance to do a call for adoption in the 
meeting itself.

Here is presentation by Torsten:
https://datatracker.ietf.org/meeting/102/materials/slides-102-oauth-sessa-jwt-response-for-oauth-token-introspection-00

Here is the document:
https://tools.ietf.org/html/draft-lodderstedt-oauth-jwt-introspection-response-01

Please let us know by August 2nd whether you accept / object to the adoption of 
this document as a starting point for work in the OAuth working group.

Regards,
Hannes & Rifaat
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for adoption of "JWT Response for OAuth TokenIntrospection"

[John Bradley]

I am in favor of adoption.


Sent from Mail for Windows 10

From: Rifaat Shekh-Yusef
Sent: Thursday, July 19, 2018 1:44 PM
To: oauth
Subject: [OAUTH-WG] Call for adoption of "JWT Response for OAuth 
TokenIntrospection"

Hi all,

This is the call for adoption of the 'JWT Response for OAuth Token 
Introspection' document following the presentation by Torsten at the Montreal 
IETF meeting where we didn't have a chance to do a call for adoption in the 
meeting itself.

Here is presentation by Torsten:
https://datatracker.ietf.org/meeting/102/materials/slides-102-oauth-sessa-jwt-response-for-oauth-token-introspection-00

Here is the document:
https://tools.ietf.org/html/draft-lodderstedt-oauth-jwt-introspection-response-01

Please let us know by August 2nd whether you accept / object to the adoption of 
this document as a starting point for work in the OAuth working group.

Regards,
Hannes & Rifaat

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

Re: [OAUTH-WG] Call for adoption of "JWT Response for OAuth Token Introspection"

[Hannes Tschofenig]

There are companies doing token introspection by the client already, see 
https://backstage.forgerock.com/docs/am/6/oauth2-guide/#sec-standards

What security implications do you see?

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Anthony Nadalin
Sent: 20 July 2018 10:07
To: Rifaat Shekh-Yusef; oauth
Subject: Re: [OAUTH-WG] Call for adoption of "JWT Response for OAuth Token 
Introspection"

I’m concerned over the security implications of a client being able to 
introspect a token, for bearer tokens this can be very problematic, so unless 
the issues with possible token theft can be addressed I don’t support this as a 
WG draft

From: OAuth  On Behalf Of Rifaat Shekh-Yusef
Sent: Thursday, July 19, 2018 10:44 AM
To: oauth 
Subject: [OAUTH-WG] Call for adoption of "JWT Response for OAuth Token 
Introspection"

Hi all,

This is the call for adoption of the 'JWT Response for OAuth Token 
Introspection' document following the presentation by Torsten at the Montreal 
IETF meeting where we didn't have a chance to do a call for adoption in the 
meeting itself.

Here is presentation by Torsten:
https://datatracker.ietf.org/meeting/102/materials/slides-102-oauth-sessa-jwt-response-for-oauth-token-introspection-00

Here is the document:
https://tools.ietf.org/html/draft-lodderstedt-oauth-jwt-introspection-response-01

Please let us know by August 2nd whether you accept / object to the adoption of 
this document as a starting point for work in the OAuth working group.

Regards,
Hannes & Rifaat
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for adoption for "Resource Indicators for OAuth 2.0"

[Brian Campbell]

The current draft does allow multiple "resource" parameters. However, there
seemed to be consensus in the WG meeting yesterday that only a single
"resource" parameter was preferable and that a client could obtain an
access token per resource (likely using a refresh token). I'm personally
sympathetic to that point. But maybe it's too restrictive. I would like to
see some more text about the complexity implications of multiple "resource"
parameters and perhaps some discouragement of doing so. I believe logical
names are more potentially useful in an STS framework like token exchange
but should be out of scope for this work.







On Fri, Jul 20, 2018 at 3:43 AM, Filip Skokan  wrote:

> Hi Torsten,
>
> > Multiple "resource" parameters may be used to indicate that the issued
> token is intended to be used at multiple resource servers.
>
> That's already in. Furthermore what about logical names for target
> services? Like was added in -03 of token exchange?
>
> Best,
> *Filip Skokan*
>
>
> On Fri, Jul 20, 2018 at 9:33 AM Torsten Lodderstedt <
> tors...@lodderstedt.net> wrote:
>
>> I support adoption of this document.
>>
>> I would like to point out (again) a single resource is not sufficient for
>> most use cases I implemented in the last couple if years. I‘m advocating
>> for enhancing the draft to support multiple resources and a clear
>> definition of the relationship between resource(s) and scope.
>>
>> Am 20.07.2018 um 08:20 schrieb n-sakimura :
>>
>> +1
>>
>>
>>
>> *From:* OAuth [mailto:oauth-boun...@ietf.org ] *On
>> Behalf Of *Brian Campbell
>> *Sent:* Friday, July 20, 2018 7:42 AM
>> *To:* Rifaat Shekh-Yusef 
>> *Cc:* oauth 
>> *Subject:* Re: [OAUTH-WG] Call for adoption for "Resource Indicators for
>> OAuth 2.0"
>>
>>
>>
>> I support adoption of this document.
>>
>>
>>
>> On Thu, Jul 19, 2018 at 4:01 PM, Rifaat Shekh-Yusef <
>> rifaat.i...@gmail.com> wrote:
>>
>> Hi all,
>>
>> This is the call for adoption of the 'Resource Indicators for OAuth 2.0'
>> document
>> following the positive call for adoption at the Montreal IETF meeting.
>>
>> Here is the document:
>> https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-02
>>
>> Please let us know by August 2nd whether you accept / object to the
>> adoption of this document as a starting point for work in the OAuth
>> working group.
>>
>> Regards,
>> Rifaat
>>
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>>
>> *CONFIDENTIALITY NOTICE: This email may contain confidential and
>> privileged material for the sole use of the intended recipient(s). Any
>> review, use, distribution or disclosure by others is strictly prohibited...
>> If you have received this communication in error, please notify the sender
>> immediately by e-mail and delete the message and any file attachments from
>> your computer. Thank you.*
>>
>> ___
>> 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
>
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for adoption of "JWT Response for OAuth Token Introspection"

[Torsten Lodderstedt]

> Am 20.07.2018 um 16:06 schrieb Anthony Nadalin 
> :
> 
> I’m concerned over the security implications of a client being able to 
> introspect a token, for bearer tokens this can be very problematic, so unless 
> the issues with possible token theft can be addressed I don’t support this as 
> a WG draft

Hi Tony,

I think this an issue for introspection in general and not specific to our 
extension.

If the token content needs to be kept confidential then the AS MUST 
authenticate the caller of the Introspection endpoint and apply an suitable 
authz policy. This is possible with Token Introspection and with our draft as 
well. 

Additionally, our draft allows to encrypt the token response, adding an extra 
layer of defense. 

kind regards,
Torsten.

>  
> From: OAuth  On Behalf Of Rifaat Shekh-Yusef
> Sent: Thursday, July 19, 2018 10:44 AM
> To: oauth 
> Subject: [OAUTH-WG] Call for adoption of "JWT Response for OAuth Token 
> Introspection"
>  
> Hi all,
>  
> This is the call for adoption of the 'JWT Response for OAuth Token 
> Introspection' document following the presentation by Torsten at the Montreal 
> IETF meeting where we didn't have a chance to do a call for adoption in the 
> meeting itself.
>  
> Here is presentation by Torsten:
> https://datatracker.ietf.org/meeting/102/materials/slides-102-oauth-sessa-jwt-response-for-oauth-token-introspection-00
>  
> Here is the document:
> https://tools.ietf.org/html/draft-lodderstedt-oauth-jwt-introspection-response-01
>  
> Please let us know by August 2nd whether you accept / object to the adoption 
> of this document as a starting point for work in the OAuth working group.
>  
> Regards,
> Hannes & Rifaat
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for adoption of "JWT Response for OAuth Token Introspection"

[Brian Campbell]

+1

On Thu, Jul 19, 2018 at 1:51 PM, William Denniss <
wdenniss=40google@dmarc.ietf.org> wrote:

> I support adoption of this document by the working group.
>
>
> On Thu, Jul 19, 2018 at 10:43 AM, Rifaat Shekh-Yusef <
> rifaat.i...@gmail.com> wrote:
>
>> Hi all,
>>
>> This is the call for adoption of the 'JWT Response for OAuth Token
>> Introspection' document following the presentation by Torsten at the
>> Montreal IETF meeting where we didn't have a chance to do a call for
>> adoption in the meeting itself.
>>
>> Here is presentation by Torsten:
>> https://datatracker.ietf.org/meeting/102/materials/slides-10
>> 2-oauth-sessa-jwt-response-for-oauth-token-introspection-00
>>
>> Here is the document:
>> https://tools.ietf.org/html/draft-lodderstedt-oauth-jwt-intr
>> ospection-response-01
>>
>> Please let us know by August 2nd whether you accept / object to the
>> adoption of this document as a starting point for work in the OAuth working
>> group.
>>
>> Regards,
>> Hannes & Rifaat
>>
>> ___
>> 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
>
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for adoption of "JWT Response for OAuth Token Introspection"

[Rob Otto]

I support this as well

On Fri, 20 Jul 2018 at 15:22, Brian Campbell  wrote:

> +1
>
> On Thu, Jul 19, 2018 at 1:51 PM, William Denniss <
> wdenniss=40google@dmarc.ietf.org> wrote:
>
>> I support adoption of this document by the working group.
>>
>>
>> On Thu, Jul 19, 2018 at 10:43 AM, Rifaat Shekh-Yusef <
>> rifaat.i...@gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> This is the call for adoption of the 'JWT Response for OAuth Token
>>> Introspection' document following the presentation by Torsten at the
>>> Montreal IETF meeting where we didn't have a chance to do a call for
>>> adoption in the meeting itself.
>>>
>>> Here is presentation by Torsten:
>>>
>>> https://datatracker.ietf.org/meeting/102/materials/slides-102-oauth-sessa-jwt-response-for-oauth-token-introspection-00
>>>
>>> Here is the document:
>>>
>>> https://tools.ietf.org/html/draft-lodderstedt-oauth-jwt-introspection-response-01
>>>
>>> Please let us know by August 2nd whether you accept / object to the
>>> adoption of this document as a starting point for work in the OAuth working
>>> group.
>>>
>>> Regards,
>>> Hannes & Rifaat
>>>
>>> ___
>>> 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
>>
>>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited...
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>


-- 
[image: Ping Identity]

Rob Otto
EMEA Field CTO/Solutions Architect
roberto...@pingidentity.com

c: +44 (0) 777 135 6092
Connect with us: [image: Glassdoor logo]

[image:
LinkedIn logo]  [image: twitter
logo]  [image: facebook logo]
 [image: youtube logo]
 [image: Google+ logo]
 [image: Blog logo]



-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for adoption for "Distributed OAuth"

[Brian Campbell]

+1 with the expectation (as discussed in the WG meeting) that it'll be
reconciled with the "resource" draft with references as appropriate

On Fri, Jul 20, 2018 at 3:28 AM, Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:

> +1
>
> Am 20.07.2018 um 08:21 schrieb n-sakimura :
>
> And if it were not obvious, YES J
>
>
>
> *From:* OAuth [mailto:oauth-boun...@ietf.org ] *On
> Behalf Of *Dick Hardt
> *Sent:* Friday, July 20, 2018 6:12 AM
> *To:* Rifaat Shekh-Yusef 
> *Cc:* oauth 
> *Subject:* Re: [OAUTH-WG] Call for adoption for "Distributed OAuth"
>
>
>
> I'm supportive. :)
>
>
>
> On Thu, Jul 19, 2018 at 4:05 PM, Rifaat Shekh-Yusef 
> wrote:
>
> Hi all,
>
>
>
> This is the call for adoption of the 'Distributed OAuth' document
>
> following the positive call for adoption at the Montreal IETF meeting.
>
>
>
> Here is the document:
>
> https://datatracker.ietf.org/doc/draft-hardt-oauth-distributed/
>
>
>
> Please let us know by August 2nd whether you accept / object to the
>
> adoption of this document as a starting point for work in the OAuth
>
> working group.
>
>
>
> Regards,
>
> Hannes & Rifaat
>
>
>
>
> ___
> 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
>
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for adoption for "Resource Indicators for OAuth 2.0"

[Mike Jones]

While I agree that a single requested resource is the common case, enough 
people have spoken up with a need for multiple requested resources over the 
years that I think everyone will be better served by leaving the ability to 
specify multiple requested resources in the specification.

   -- Mike

From: OAuth  On Behalf Of Brian Campbell
Sent: Friday, July 20, 2018 10:18 AM
To: Filip Skokan 
Cc: oauth 
Subject: Re: [OAUTH-WG] Call for adoption for "Resource Indicators for OAuth 
2.0"

The current draft does allow multiple "resource" parameters. However, there 
seemed to be consensus in the WG meeting yesterday that only a single 
"resource" parameter was preferable and that a client could obtain an access 
token per resource (likely using a refresh token). I'm personally sympathetic 
to that point. But maybe it's too restrictive. I would like to see some more 
text about the complexity implications of multiple "resource" parameters and 
perhaps some discouragement of doing so. I believe logical names are more 
potentially useful in an STS framework like token exchange but should be out of 
scope for this work.







On Fri, Jul 20, 2018 at 3:43 AM, Filip Skokan 
mailto:panva...@gmail.com>> wrote:
Hi Torsten,

> Multiple "resource" parameters may be used to indicate that the issued token 
> is intended to be used at multiple resource servers.

That's already in. Furthermore what about logical names for target services? 
Like was added in -03 of token exchange?

Best,
Filip Skokan


On Fri, Jul 20, 2018 at 9:33 AM Torsten Lodderstedt 
mailto:tors...@lodderstedt.net>> wrote:
I support adoption of this document.

I would like to point out (again) a single resource is not sufficient for most 
use cases I implemented in the last couple if years. I‘m advocating for 
enhancing the draft to support multiple resources and a clear definition of the 
relationship between resource(s) and scope.

Am 20.07.2018 um 08:20 schrieb n-sakimura 
mailto:n-sakim...@nri.co.jp>>:
+1

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Friday, July 20, 2018 7:42 AM
To: Rifaat Shekh-Yusef mailto:rifaat.i...@gmail.com>>
Cc: oauth mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] Call for adoption for "Resource Indicators for OAuth 
2.0"

I support adoption of this document.

On Thu, Jul 19, 2018 at 4:01 PM, Rifaat Shekh-Yusef 
mailto:rifaat.i...@gmail.com>> wrote:
Hi all,

This is the call for adoption of the 'Resource Indicators for OAuth 2.0' 
document
following the positive call for adoption at the Montreal IETF meeting.

Here is the document:
https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-02

Please let us know by August 2nd whether you accept / object to the
adoption of this document as a starting point for work in the OAuth
working group.

Regards,
Rifaat

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


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited..  If you have 
received this communication in error, please notify the sender immediately by 
e-mail and delete the message and any file attachments from your computer. 
Thank you.
___
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


CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited..  If you have 
received this communication in error, please notify the sender immediately by 
e-mail and delete the message and any file attachments from your computer. 
Thank you.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for adoption of "JWT Response for OAuth Token Introspection"

[Phil Hunt]

+1 adoption

I have always been concerned about clients doing introspection. Use of jwt 
helps because responses further restricted rather than less (jwe). 

Phil

> On Jul 20, 2018, at 7:25 AM, Rob Otto 
>  wrote:
> 
> I support this as well 
> 
>> On Fri, 20 Jul 2018 at 15:22, Brian Campbell 
>>  wrote:
>> +1 
>> 
>>> On Thu, Jul 19, 2018 at 1:51 PM, William Denniss 
>>>  wrote:
>>> I support adoption of this document by the working group.
>>> 
>>> 
 On Thu, Jul 19, 2018 at 10:43 AM, Rifaat Shekh-Yusef 
  wrote:
 Hi all,
 
 This is the call for adoption of the 'JWT Response for OAuth Token 
 Introspection' document following the presentation by Torsten at the 
 Montreal IETF meeting where we didn't have a chance to do a call for 
 adoption in the meeting itself.
 
 Here is presentation by Torsten:
 https://datatracker.ietf.org/meeting/102/materials/slides-102-oauth-sessa-jwt-response-for-oauth-token-introspection-00
 
 Here is the document:
 https://tools.ietf.org/html/draft-lodderstedt-oauth-jwt-introspection-response-01
 
 Please let us know by August 2nd whether you accept / object to the 
 adoption of this document as a starting point for work in the OAuth 
 working group.
 
 Regards,
 Hannes & Rifaat
 
 ___
 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
>>> 
>> 
>> 
>> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
>> material for the sole use of the intended recipient(s). Any review, use, 
>> distribution or disclosure by others is strictly prohibited...  If you have 
>> received this communication in error, please notify the sender immediately 
>> by e-mail and delete the message and any file attachments from your 
>> computer. Thank you.___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> 
> -- 
>   
> Rob Otto  
> EMEA Field CTO/Solutions Architect
> 
> roberto...@pingidentity.com   
>   
> c: +44 (0) 777 135 6092
> Connect with us:
> 
> 
> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
> material for the sole use of the intended recipient(s). Any review, use, 
> distribution or disclosure by others is strictly prohibited..  If you have 
> received this communication in error, please notify the sender immediately by 
> e-mail and delete the message and any file attachments from your computer. 
> Thank you.
> ___
> 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] Call for adoption of "JWT Response for OAuth Token Introspection"

[Mark Dobrinic]

I +1 this,

but at the same time, I'm wondering what happened with the argument that
this should be solved by Token Exchange instead of Introspect?

Cheers!

Mark


On 20/07/18 17:39, Phil Hunt wrote:
> +1 adoption
> 
> I have always been concerned about clients doing introspection. Use of
> jwt helps because responses further restricted rather than less (jwe). 
> 
> Phil
> 
> On Jul 20, 2018, at 7:25 AM, Rob Otto
>  > wrote:
> 
>> I support this as well 
>>
>> On Fri, 20 Jul 2018 at 15:22, Brian Campbell
>> > > wrote:
>>
>> +1
>>
>> On Thu, Jul 19, 2018 at 1:51 PM, William Denniss
>> > > wrote:
>>
>> I support adoption of this document by the working group.
>>
>>
>> On Thu, Jul 19, 2018 at 10:43 AM, Rifaat Shekh-Yusef
>> mailto:rifaat.i...@gmail.com>> wrote:
>>
>> Hi all,
>>
>> This is the call for adoption of the 'JWT Response for
>> OAuth Token Introspection' document following the
>> presentation by Torsten at the Montreal IETF meeting where
>> we didn't have a chance to do a call for adoption in the
>> meeting itself.
>>
>> Here is presentation by Torsten:
>> 
>> https://datatracker.ietf.org/meeting/102/materials/slides-102-oauth-sessa-jwt-response-for-oauth-token-introspection-00
>>
>> Here is the document:
>> 
>> https://tools.ietf.org/html/draft-lodderstedt-oauth-jwt-introspection-response-01
>>
>> Please let us know by August 2nd whether you accept /
>> object to the adoption of this document as a starting
>> point for work in the OAuth working group.
>>
>> Regards,
>> Hannes & Rifaat
>>
>> ___
>> 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
>>
>>
>>
>> /CONFIDENTIALITY NOTICE: This email may contain confidential and
>> privileged material for the sole use of the intended recipient(s).
>> Any review, use, distribution or disclosure by others is strictly
>> prohibited...  If you have received this communication in error,
>> please notify the sender immediately by e-mail and delete the
>> message and any file attachments from your computer. Thank
>> you./___
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>> -- 
>> Ping Identity
>>    
>> Rob Otto 
>> EMEA Field CTO/Solutions Architect   
>> roberto...@pingidentity.com  
>>
>> c: +44 (0) 777 135 6092  
>>
>> Connect with us: Glassdoor logo
>> 
>> LinkedIn logo  twitter logo
>>    facebook logo
>>   youtube logo
>> Google+ logo
>>  Blog logo
>>   
>>
>> 
>>
>> /CONFIDENTIALITY NOTICE: This email may contain confidential and
>> privileged material for the sole use of the intended recipient(s). Any
>> review, use, distribution or disclosure by others is strictly
>> prohibited..  If you have received this communication in error, please
>> notify the sender immediately by e-mail and delete the message and any
>> file attachments from your computer. Thank you./
>> ___
>> 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] [Gen-art] Genart last call review of draft-ietf-oauth-device-flow-10

[Robert Sparks]

As far as I can tell, there has been no response to this. The document 
revision just updated a reference to reflect an rfc having been published.


Apologies if I missed a response.

RjS


On 6/11/18 12:20 PM, Robert Sparks wrote:

Reviewer: Robert Sparks
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-oauth-device-flow-10
Reviewer: Robert Sparks
Review Date: 2018-06-11
IETF LC End Date: 2018-06-12
IESG Telechat date: Not scheduled for a telechat

Summary: Ready for publication as a Proposed Standard RFC, but with nits to
consider

Nits/editorial comments:

In 3.5 "the client MUST use a reasonable default polling interval" is not
testable. Who determines "reasonable"? At the very least, you should add some
text about how to determine what "reasonable" is for a given device, and add
some text that says don't poll faster than earlier responses limited you to.
For example, if the response at step B in the introductory diagram had an
explicit interval of 15, but a slow-down response to an E message didn't have
an explicit interval, you don't want them to default to, say 5 seconds (because
that's what the example in section 3.2 said, so it must be reasonable).

In 3.3, you say the device_code MUST NOT be displayed or communicated. Is there
a security property that's lost if there is? Or is this just saying "Don't
waste space or the user's time"?

The last paragraph of section 6.1 feels like a recipe for false positives, and
for bug-entrenched code. Please reconsider it.

You need line-folding in the example in section 3.2


___
Gen-art mailing list
gen-...@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art


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

Re: [OAUTH-WG] Call for adoption for "Resource Indicators for OAuth 2.0"

[Dick Hardt]

There are a few places where multiple resources could be used:

One is in the code flow where it is desirable to optimize the user
experience so that the user is granting authorization once, and not
multiple times.

The second is in the access token request, which leads to the third
instance, which is in the access token. If an access token is being
returned for each resource, then making a single request is simpler, it
seems to complicate the interface more.

If we want to have audience constrained access tokens, then it is safer to
have only one resource in the access token - otherwise each resource can
use the access token to access the other resources.

All of these examples assume that it is a single AS. Supporting multiple AS
in a single request seems super complicated and wrought with security and
trust issues.




On Fri, Jul 20, 2018 at 11:13 AM, Mike Jones <
Michael.Jones=40microsoft@dmarc.ietf.org> wrote:

> While I agree that a single requested resource is the common case, enough
> people have spoken up with a need for multiple requested resources over the
> years that I think everyone will be better served by leaving the ability to
> specify multiple requested resources in the specification.
>
>
>
>-- Mike
>
>
>
> *From:* OAuth  *On Behalf Of * Brian Campbell
> *Sent:* Friday, July 20, 2018 10:18 AM
> *To:* Filip Skokan 
>
> *Cc:* oauth 
> *Subject:* Re: [OAUTH-WG] Call for adoption for "Resource Indicators for
> OAuth 2.0"
>
>
>
> The current draft does allow multiple "resource" parameters. However,
> there seemed to be consensus in the WG meeting yesterday that only a single
> "resource" parameter was preferable and that a client could obtain an
> access token per resource (likely using a refresh token). I'm personally
> sympathetic to that point. But maybe it's too restrictive. I would like to
> see some more text about the complexity implications of multiple "resource"
> parameters and perhaps some discouragement of doing so. I believe logical
> names are more potentially useful in an STS framework like token exchange
> but should be out of scope for this work.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Fri, Jul 20, 2018 at 3:43 AM, Filip Skokan  wrote:
>
> Hi Torsten,
>
>
>
> > Multiple "resource" parameters may be used to indicate that the issued
> token is intended to be used at multiple resource servers.
>
>
>
> That's already in. Furthermore what about logical names for target
> services? Like was added in -03 of token exchange?
>
>
> Best,
> *Filip Skokan*
>
>
>
>
>
> On Fri, Jul 20, 2018 at 9:33 AM Torsten Lodderstedt <
> tors...@lodderstedt.net> wrote:
>
> I support adoption of this document.
>
>
>
> I would like to point out (again) a single resource is not sufficient for
> most use cases I implemented in the last couple if years. I‘m advocating
> for enhancing the draft to support multiple resources and a clear
> definition of the relationship between resource(s) and scope.
>
>
> Am 20.07.2018 um 08:20 schrieb n-sakimura :
>
> +1
>
>
>
> *From:* OAuth [mailto:oauth-boun...@ietf.org ] *On
> Behalf Of *Brian Campbell
> *Sent:* Friday, July 20, 2018 7:42 AM
> *To:* Rifaat Shekh-Yusef 
> *Cc:* oauth 
> *Subject:* Re: [OAUTH-WG] Call for adoption for "Resource Indicators for
> OAuth 2.0"
>
>
>
> I support adoption of this document.
>
>
>
> On Thu, Jul 19, 2018 at 4:01 PM, Rifaat Shekh-Yusef 
> wrote:
>
> Hi all,
>
> This is the call for adoption of the 'Resource Indicators for OAuth 2.0'
> document
> following the positive call for adoption at the Montreal IETF meeting.
>
> Here is the document:
> https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-02
>
> Please let us know by August 2nd whether you accept / object to the
> adoption of this document as a starting point for work in the OAuth
> working group.
>
> Regards,
> Rifaat
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited...
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*
>
> ___
> 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
>
>
>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> re

[OAUTH-WG] Progressing the HTTP parameter encoding for OAuth PoP Key Distribution

[Hannes Tschofenig]

Hi all,

after several discussions we believe that we now have a proposal for moving 
forward on this topic.
We plan to update the expired draft  
and
(1) remove the audience parameter and replace it with a separately-specified 
resource parameter,
(2) remove the alg parameter,
(3) update the procedures for requesting and obtaining keying material,
(4) Synchronize with the ACE and WebRTC work to make sure that their use cases 
are appropriately covered.

Regarding (1): The meeting participants have decided to standardize an 
audience-alike parameter (in the form of a requested resource identifier) at 
this weeks IETF OAuth meeting. For that purpose, working group adoption of 
draft-campbell-oauth-resource-indicators is under way.  Only a reference to 
that document will be needed.

Regarding (2): Removal of the alg parameter will simplify the document and does 
not appear to be necessary for the currently investigated use cases. This 
assumption will have to be verified.

Regarding (3): Currently, the ACE-OAuth document and the 
 use different parameter names. 
Furthermore, those parameter names may be in conflict with other, already 
standardized parameter names. Hence, some parameters may need to be renamed. 
The plan is to focus on the following, minimal functionality only: server-side 
symmetric key generation and client-side public key registration to the AS. 
Furthermore, the encoding of the key transport will have to take the different 
token formats and protocols into account.

This approach will allow the ACE and WebRTC work to reference the generic PoP 
key distribution document without having to specify their own duplicate 
functionality.

We are planning to update  next week 
to have something to review.

Ciao
Hannes & Rifaat
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] updated Distributed OAuth ID

[David Waite]

> On Jul 20, 2018, at 2:33 AM, n-sakimura  wrote:
> 
> I did not quite follow why CORS is relevant here. We are just talking about 
> the client to server communication, and there are no embedded resources in 
> the response. Could you kindly elaborate a little, please? 

Sure!  It is effectively an additional (complex) restriction on 
implementation/capabilities of CORS and the design of the resources.

There are five possible access results for a resource that come to mind:
1. Client does not have authorization but gets a (possibly limited) entity 
response
2. Client does not have authorization and is challenged
3. Client has authorization and gets a (possibly customized) entity response
4. Client has insufficient authorization and is challenged (e.g. for a new 
access token, possibly with more scopes)
5. Client has insufficient authorization and is refused access

The CORS policies returned for 1 and 3 may be different than 2 and 4, may be 
different for 5, and may come from different infrastructure (such as an 
authenticating reverse proxy “gateway”). Note also that cases 1 and 3 may have 
a WWW-Authenticate header on the response, indicating that providing 
authorization may return a different entity response.

One way to handle remote access for all of these cases with commonality would 
be to expose the WWW-Authenticate header via the CORS policy.

With the Link header used as well, you would need to also expose the Link 
header in all of these cases (or at least 1-4). However, the Link header can 
return many relations beyond this one authorization use case, and you would be 
exposing those all-or-nothing. 

You effectively lose the ability to regulate visibility of the Link header via 
CORS, and must resort to selective disclosure of headers as your mechanism of 
control (or serialize those links in another way such as within the content 
body, when an available option)

-DW

>  
> For the second point, since it was discussed in the WG meeting yesterday, I 
> will defer to that discussion.
>  
> Best, 
>  
> Nat Sakimura
>  
>  
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of David Waite
> Sent: Thursday, July 19, 2018 4:55 PM
> To: Dick Hardt 
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] updated Distributed OAuth ID
>  
> Four comments.
>  
> First: What is the rationale for including the parameters as Link headers 
> rather than part of the WWW-Authenticate challenge, e.g.:
>  
> WWW-Authenticate: Bearer realm="example_realm",
>  scope="example_scope",
>  error=“invalid_token",
> resource_uri="https://api.example.com/resource 
> ",
> 
> oauth_server_metadata_uris="https://as.example.com/.well-known/oauth-authorization-server
>   
> https://different-as.example.com/.well-known/oauth-authorization-server 
> "
>  
> 
> My understanding is that the RFC6750 auth-params are extensible (but not 
> currently part of any managed registry.)
>  
> One reason to go with this vs Link headers is CORS policy - exposing Link 
> headers to a remote client must be done all or nothing as part of the CORS 
> policy, and can’t be limited by the kind of link.
>  
> Second: (retaining link format) Is there a reason the metadata location is 
> specified the way it is? It seems like
>  
>  >; 
> rel=“oauth_server_metadata_uri"
>  
> should be
>  
> >; rel=“oauth_issuer"
>  
> OAuth defines the location of metadata under the .well-known endpoint as a 
> MUST. An extension of OAuth may choose from at least three different methods 
> for handling extensions beyond this:
> 1. Add additional keys to the oauth-authorization-server metadata
> 2. Add additional resources to .well-known for clients to supporting their 
> extensions to attempt to resolve, treating ‘regular’ OAuth as a fallback.
> 3. Define their own parameter, such as rel=“specialauth_issuer”, potentially 
> using a different mechanism for specifying metadata
>  
> Given all this, it seems appropriate to only support specifying of 
> metadata-supplying issuers, not metadata uris.
>  
> Third: I have doubts of the usefulness of resource_uri in parallel to both 
> the client requested URI and the Authorization “realm” parameter.
>  
> As currently defined, the client would be the one enforcing (or possibly 
> ignoring) static policy around resource URIs - that a resource URI is 
> arbitrary except in that it must match the host (and scheme/port?) of the 
> requested URI. The information on the requested URI by the client is not 
> shared between the client and AS for it to do its own policy verification. It 
> would seem better to send the client 

Re: [OAUTH-WG] updated Distributed OAuth ID

[David Waite]

There is also existing software that expects to be able to act/respond based 
only on the WWW-Authenticate header. See

https://hc.apache.org/httpcomponents-client-4.5.x/httpclient/apidocs/org/apache/http/auth/AuthScheme.html#processChallenge(org.apache.http.Header)
 


-DW

> On Jul 20, 2018, at 2:33 AM, n-sakimura  wrote:
> 
> Hi David, 
>  
> Thanks for the comment, and sorry for the delay in my reply.
>  
> Doing it with Web Linking [RFC8288]  has several advantages.
>  
> It is standard based J It is just a matter of registering link relations to 
> the IANA Link Relation Type Registry, and it is quite widely used.
> No or very little coding needed: Other than adding some HTTP server 
> configuration, the rest stays the same as RFC6750.
> Standard interface: this kind of metadata is applicable not only for letting 
> the client find the appropriate authorization server but for other metadata 
> as well. Also, other endpoints as long as it is supporting the direct 
> communication with the client, can provide relevant metadata with it without 
> going through the client authorization.
>  
> I did not quite follow why CORS is relevant here. We are just talking about 
> the client to server communication, and there are no embedded resources in 
> the response. Could you kindly elaborate a little, please? 
>  
> For the second point, since it was discussed in the WG meeting yesterday, I 
> will defer to that discussion.
>  
> Best, 
>  
> Nat Sakimura
>  
>  
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of David Waite
> Sent: Thursday, July 19, 2018 4:55 PM
> To: Dick Hardt 
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] updated Distributed OAuth ID
>  
> Four comments.
>  
> First: What is the rationale for including the parameters as Link headers 
> rather than part of the WWW-Authenticate challenge, e.g.:
>  
> WWW-Authenticate: Bearer realm="example_realm",
>  scope="example_scope",
>  error=“invalid_token",
> resource_uri="https://api.example.com/resource 
> ",
> 
> oauth_server_metadata_uris="https://as.example.com/.well-known/oauth-authorization-server
>   
> https://different-as.example.com/.well-known/oauth-authorization-server 
> "
>  
> 
> My understanding is that the RFC6750 auth-params are extensible (but not 
> currently part of any managed registry.)
>  
> One reason to go with this vs Link headers is CORS policy - exposing Link 
> headers to a remote client must be done all or nothing as part of the CORS 
> policy, and can’t be limited by the kind of link.
>  
> Second: (retaining link format) Is there a reason the metadata location is 
> specified the way it is? It seems like
>  
>  >; 
> rel=“oauth_server_metadata_uri"
>  
> should be
>  
> >; rel=“oauth_issuer"
>  
> OAuth defines the location of metadata under the .well-known endpoint as a 
> MUST. An extension of OAuth may choose from at least three different methods 
> for handling extensions beyond this:
> 1. Add additional keys to the oauth-authorization-server metadata
> 2. Add additional resources to .well-known for clients to supporting their 
> extensions to attempt to resolve, treating ‘regular’ OAuth as a fallback.
> 3. Define their own parameter, such as rel=“specialauth_issuer”, potentially 
> using a different mechanism for specifying metadata
>  
> Given all this, it seems appropriate to only support specifying of 
> metadata-supplying issuers, not metadata uris.
>  
> Third: I have doubts of the usefulness of resource_uri in parallel to both 
> the client requested URI and the Authorization “realm” parameter.
>  
> As currently defined, the client would be the one enforcing (or possibly 
> ignoring) static policy around resource URIs - that a resource URI is 
> arbitrary except in that it must match the host (and scheme/port?) of the 
> requested URI. The information on the requested URI by the client is not 
> shared between the client and AS for it to do its own policy verification. It 
> would seem better to send the client origin to the AS for it to do 
> (potential) policy verification, rather than relying on clients to implement 
> it for them based on static spec policy.
>  
> The name “resource URI” is also confusing, as I would expect it to be the URI 
> that was requested by the client. The purpose of this parameter is a bit 
> confusing, as it is only defined as “An OAuth 2.0 Resource Endpoint specified 
> in [RFC6750] section 3.2 - where the term doe