Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-par-00.txt

[Brian Campbell]

I think you did call it an API in the first place? :)

endpoint is fine too though

I believe Aaron's main point was that calling this REST is a bit of a
stretch

On Mon, Sep 30, 2019 at 9:57 AM Torsten Lodderstedt 
wrote:

> I wouldn't call it an API. What about just calling it an "HTTP endpoint"?
>
> > On 30. Sep 2019, at 07:52, Brian Campbell 
> wrote:
> >
> >
> >
> > On Thu, Sep 26, 2019 at 9:30 AM Aaron Parecki  wrote:
> > > The pushed authorization request endpoint shall be a RESTful API
> >
> > I would drop the term RESTful and just say "HTTP API", as this
> > description is arguably RESTful at best.
> >
> > +1
> >
> >
> > 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.
>
>

-- 
_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] New Version Notification for draft-lodderstedt-oauth-par-00.txt

[Brian Campbell]

On Thu, Sep 26, 2019 at 10:50 AM Justin Richer  wrote:

>  If, for whatever reason, it is required that this value is
> actually a URI, is there some expected namespace to use other than
> "example"? I worry that if all the examples in the spec are just
> "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2" then developers will end up
> using the text "example" because they don't understand why it's there,
> and then it serves no purpose really.’
>
>
> This field must be a URI, as per JAR:
>
>request_uri  The absolute URI as defined by RFC3986 
>  [RFC3986 
> ] that
>   points to the Request Object (Section 2.1 
> ) that 
> holds
>   authorization request parameters stated in section 4 
>  of OAuth 
> 2.0
>   [RFC6749 ].
>
> Somewhat awkwardly, the JAR spec currently states that the AS has to do an
> HTTP GET on the request URI, so that will need to be fixed in JAR before it
> goes forward. I don’t think that was always the case though, and I’m not
> sure how that changed.
>

JAR does have a somewhat awkward allowance for not doing a GET in
https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-5.2.3 saying
an AS "MUST send an HTTP "GET" request to the request_uri to retrieve the
referenced Request Object, unless it is stored in a way so that it can
retrieve it through other mechanism securely."

So I'm guessing maybe nothing actually changed but it's just hard to find
in the document.



> As for the namespace, “example” is ok for an example URN. The problem with
> URNs is that nobody really understands how to do domain-safe fully
> compliant URNs. So perhaps we should instead use “urn:fdc:example..com:….”
> Instead (as per https://tools.ietf.org/html/rfc4198).
>

Something else to consider additionally or alternately is that the document
could provide some suggestions/guidance or even requirements on the
structure of the URN for this self referential case. It could, for example,
use the RFC6755 subnamespace and registry and be of the form
urn:ietf:params:oauth:request_uri: or
urn:ietf:params:oauth:request_uri; or
urn:ietf:params:oauth:request_uri?value= or
urn:ietf:params:oauth:request_uri# or however the proper way to do
that would be.

-- 
_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] Fwd: New Version Notification for draft-lodderstedt-oauth-par-00.txt

[Brian Campbell]

On Thu, Sep 26, 2019 at 9:30 AM Aaron Parecki  wrote:

> > Depending on client type and authentication method, the request might
> >   also include the "client_id" parameter.
>
> I assume this is hinting at the difference between public clients
> sending only the "client_id" parameter and confidential clients
> sending only the HTTP Basic Authorization header which includes both
> the client ID and secret? It would probably be helpful to call out
> these two common examples if I am understanding this correctly,
> otherwise it seems pretty vague.
>

What this is trying to convey is that because client authentication at this
Pushed Authorization Request Endpoint happens the same way as at the token
endpoint (and other endpoints called directly by the client) the client_id
parameter will sometimes be present but not necessarily as some types of
client auth use the client_id parameter (none, client_secret_post,
tls_client_auth, self_signed_tls_client_auth) and some don't
(client_secret_basic, client_secret_jwt, private_key_jwt).

Although the draft does later say "The AS MUST validate the request the
same way as at the authorization endpoint" which I think could reasonably
be interpreted as requiring client_id.  e.g.,
https://tools.ietf.org/html/rfc6749?#section-4.1.1 &
https://tools.ietf.org/html/rfc6749?#section-4.2.1

So perhaps the sentence in question should be removed and have client_id be
a required parameter at the PAR endpoint.

-- 
_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] Fwd: New Version Notification for draft-lodderstedt-oauth-par-00.txt

[Brian Campbell]

On Thu, Sep 26, 2019 at 9:30 AM Aaron Parecki  wrote:

> > The pushed authorization request endpoint shall be a RESTful API
>
> I would drop the term RESTful and just say "HTTP API", as this
> description is arguably RESTful at best.
>

+1

-- 
_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] WGLC on draft-ietf-oauth-incremental-authz-01

[Brian Campbell]

Just noticed that something is missing in
https://tools.ietf.org/html/draft-ietf-oauth-incremental-authz-02#section-5
where it has just, "(Section 4.1.4 of )"

On Thu, Sep 12, 2019 at 8:40 AM Hannes Tschofenig 
wrote:

> Thanks for the correction; yes – the most recent version is -02 and I
> posted an old link.
>
>
>
>
>
> *From:* Eve Maler 
> *Sent:* Donnerstag, 12. September 2019 16:16
> *To:* Hannes Tschofenig 
> *Subject:* Re: [OAUTH-WG] WGLC on draft-ietf-oauth-incremental-authz-01
>
>
>
> I think you mean
> https://tools.ietf.org/html/draft-ietf-oauth-incremental-authz-02?
>
> Eve Maler (sent from my iPad) | cell +1 425 345 6756
>
>
> On Sep 11, 2019, at 4:22 AM, Hannes Tschofenig 
> wrote:
>
> Hi all,
>
>
>
> We are starting a WGLC on the "OAuth 2.0 Incremental Authorization" draft..
> You can find the document here:
>
> https://tools.ietf.org/html/draft-ietf-oauth-incremental-authz-01
>
>
>
> Please review the document and provide feedback.
>
>
>
> The WGLC will end September 25th, 2019.
>
>
>
> 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
>
> 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
>

-- 
_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] Minor issue in https://tools.ietf.org/html/draft-ietf-oauth-jwt-introspection-response-08

[Brian Campbell]

That should probably be fixed unless the example was intended to be set
nearly 48,000 years* in the future.


* assuming my math is correct and you know the old saying about assuming

On Sun, Sep 22, 2019 at 8:55 AM Neil Madden 
wrote:

> Just noticed that the iat/exp claims in the example JWT response in
> section 5 appear to be in milliseconds rather than the standard seconds.
>
> — Neil
> ___
> 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-WG] draft-ietf-oauth-reciprocal-04 WGLC feedback

[Brian Campbell]

I reviewed draft-ietf-oauth-reciprocal-04 and I do not believe that the
document is yet sufficiently mature to send to the IESG.  A (not
necessarily complete) set of comments and feedback follow.

Sections 1 & 2:
I realize this isn't particularly actionable but have to admit that I had a
hard time reading and really understanding the introduction in section 1
and flow in section 2. And that's coming from someone who came to this
document with some general familiarity with OAuth and a rough idea of what
the draft was aiming to accomplish.

Section 2.1:
  "When party B is providing an access token response per [RFC6749]
   4.1.4, 4.2.1, 4.3.3 or 4.4.3, party B MAY include an additional query
   component in the redirection URI to indicate the scope requested in
   the reciprocal grant:"

4.1.4, 4.3.3 and 4.4.3 of RFC6749 are access token responses to
Authorization Code Grant , Resource Owner Password Credentials Grant, and
Client Credentials Grant requests respectively (I did have to look those
up). Which are HTTP responses with JSON in the body. So an "additional
query  component in the redirection URI" doesn't make any sense in that
context. Perhaps it's supposed to be an additional JSON
member/parameter/element (whatever the right term is is with JSON)? But,
that said, does this Reciprocal thing even make sense in response to
Resource Owner Password Credentials Grant, and Client Credentials Grant
requests? But if they do, then what about Extension grants (i.e. SAML, JWT,
device, etc) in sec 4.5?

4.2.1 of RFC6749 is the Authorization Request of the Implicit Grant, which
seems out of place here.

"  If an authorization code grant access token response per [RFC6749]
   4.1.4, an example successful response (with extra line breaks for
   display purposes only):"

I don't think that's a complete sentence.

"   Content-Type: application/json;charset=UTF-8"

I don't believe charset is needed or used application/json.

" "token_type":"example","

Really? I guess it's not wrong but using a 'real' value for token type
might be easier on readers.

" "example_parameter":"example_value""

Seems out of place and unnecessary for an example in this draft.

"   If an authorization code grant access token response per [RFC6749]
   4.2.2, an example successful response (with extra line breaks for
   display purposes only):

   HTTP/1.1 302 Found
   Location: http://example.com/cb#
   access_token=2YotnFZFEjr1zCsicMWpAA&
   state=xyz&
   token_type=example&
   expires_in=3600&
   reciprocal="example_scope" "

RFC6749's 4.2.2 is implicit and the example that follows is implicit but
the text there says authorization code. That text leading up to the example
also doesn't seem to form a complete sentence. A token type of example
seems odd and potentially confusing here too. I don't think "example_scope"
should be quoted in the example but if it really is supposed to be, then
the quotes need to be form-urlencoded (%22).

Should this reciprocal stuff even be defined for the implicit grant? Does
it really make sense? Does the WG want to keep building on implicit?

"   When party B is providing an authorization response per [RFC6749]
   4.1.2, party B MAY include an additional query component in the
   redirection URI to indicate the scope requested in the reciprocal
   grant."

4.1.2 of RFC6749 is the Authorization Response of the Authorization Request
for the Authorization Code Grant flow. Earlier in the same section, I think
the reciprocal parameter is defined for access token responses to
Authorization Code Grant request. So does there need to be two different
ways to send the reciprocal parameter during the same flow? Or maybe I'm
misunderstanding? It's certainly possible as I'm having a hard time
following this section.

Section 2.2:
According to RFC6749, "The token endpoint is used by the client to obtain
an access token by presenting its authorization grant or refresh token."
And in RFC6749 there are defined constructs and semantics for success and
error responses from the token endpoint. However the grant type in section
2.2 of this draft is kind of the opposite of that where the reciprocal
authorization code is being pushed/sent to the token endpoint and nothing
is being obtained/returned in the response to that request. It's also means
the reciprocal authorization code is being delivered to the AS even though
it is intended for the client.

This is arguably an illegitimate use of the given extension points in OAuth
and shouldn't be done or allowed. Off hand, it would seem more appropriate
to have/define a new client endpoint  to receive these pushed reciprocal
authorization codes.  At best it's a major abuse of those extension points
and the document, if it persists in doing things this way (even though I
don't think it should), it needs to have some pretty good explanation for
how and why this one particular grant type completely diverges from what is
defined in RFC6749.

On a slightly more m

Re: [OAUTH-WG] Adam Roach's No Objection on draft-ietf-oauth-resource-indicators-05: (with COMMENT)

[Brian Campbell]

I don't have any aversion to adding something but I've been at a bit of a
loss as to what exactly to say or how to say it. But here's a stab at
something. How about the following sentence, which kind of layers your
words onto the text that Barry previously suggested:

"It SHOULD NOT include a query component, but it is recognized that there
are cases that make a query component a useful and necessary part of the
resource parameter, such as when query parameter(s) are used to scope
requests to an application."

On Thu, Sep 5, 2019 at 6:41 PM Adam Roach  wrote:

> I don't have a strong objection to it. I still think that, if this is
> allowed (even as a SHOULD NOT), we need clarity that any query
> parameters that are used to scope queries to an application necessarily
> form part of the resource parameter. It's significantly less important,
> though, now that the practice is discouraged, and I won't mind if you go
> ahead without adding such text.
>
> /a
>
> On 9/5/19 4:01 PM, Barry Leiba wrote:
> > Thanks, Brian.  I hope Adam is happy with that as well.
> >
> > Barry
> >
> > On Thu, Sep 5, 2019 at 3:01 PM Brian Campbell
> >  wrote:
> >> I went ahead with this in -07.
> >>
> >> On Wed, Sep 4, 2019 at 3:07 PM Brian Campbell <
> bcampb...@pingidentity.com> wrote:
> >>> Thanks Barry, I kinda like it. Although I'm a bit hesitant to make a
> change like that at this stage. I guess I'd be looking for a little more
> buy-in from folks first. Though it's not actually a functional breaking
> change. So maybe okay to just go with.
> >>>
> >>> On Wed, Sep 4, 2019 at 2:54 PM Barry Leiba 
> wrote:
> >>>>> Yeah, with query parameters lacking the hierarchical semantics that
> the path component has, it is much less clear. In fact, an earlier revision
> of the draft forbid the query part as I was trying to avoid the ambiguity
> that it brings. But there were enough folks with some use case for it that
> it made its way back in. While I am sympathetic to the point you're making
> here, I'd prefer to not codify the practice any further by way of example
> in the document.
> >>>> Is it perhaps reasonable to discourage the use of a query component
> >>>> while still allowing it?  Maybe a "SHOULD NOT", such as this?:
> >>>>
> >>>> OLD
> >>>>Its value MUST be an absolute URI, as specified by
> >>>>Section 4.3 of [RFC3986], which MAY include a query component
> but
> >>>>MUST NOT include a fragment component.
> >>>> NEW
> >>>>Its value MUST be an absolute URI, as specified by
> >>>>Section 4.3 of [RFC3986].  The URI MUST NOT include
> >>>>a fragment component.  It SHOULD NOT include a query
> >>>>component, but it is recognized that there are cases that
> >>>>make a query component useful.
> >>>> END
> >>>>
> >>>> What do you think?
> >>>>
> >>>> Barry
> >>
> >> 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.
>
>
>

-- 
_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] Adam Roach's No Objection on draft-ietf-oauth-resource-indicators-05: (with COMMENT)

[Brian Campbell]

I went ahead with this in -07.

On Wed, Sep 4, 2019 at 3:07 PM Brian Campbell 
wrote:

> Thanks Barry, I kinda like it. Although I'm a bit hesitant to make a
> change like that at this stage. I guess I'd be looking for a little more
> buy-in from folks first. Though it's not actually a functional breaking
> change. So maybe okay to just go with.
>
> On Wed, Sep 4, 2019 at 2:54 PM Barry Leiba 
> wrote:
>
>> > Yeah, with query parameters lacking the hierarchical semantics that the
>> path component has, it is much less clear. In fact, an earlier revision of
>> the draft forbid the query part as I was trying to avoid the ambiguity that
>> it brings. But there were enough folks with some use case for it that it
>> made its way back in. While I am sympathetic to the point you're making
>> here, I'd prefer to not codify the practice any further by way of example
>> in the document.
>>
>> Is it perhaps reasonable to discourage the use of a query component
>> while still allowing it?  Maybe a "SHOULD NOT", such as this?:
>>
>> OLD
>>   Its value MUST be an absolute URI, as specified by
>>   Section 4.3 of [RFC3986], which MAY include a query component but
>>   MUST NOT include a fragment component.
>> NEW
>>   Its value MUST be an absolute URI, as specified by
>>   Section 4.3 of [RFC3986].  The URI MUST NOT include
>>   a fragment component.  It SHOULD NOT include a query
>>   component, but it is recognized that there are cases that
>>   make a query component useful.
>> END
>>
>> What do you think?
>>
>> Barry
>>
>

-- 
_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] I-D Action: draft-ietf-oauth-resource-indicators-06.txt

[Brian Campbell]

er... and also -07

On Thu, Sep 5, 2019 at 12:52 PM Brian Campbell 
wrote:

> -06 should address comments from IESG evaluation
>
> -- Forwarded message -
> From: 
> Date: Thu, Sep 5, 2019 at 12:45 PM
> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-resource-indicators-06.txt
> To: 
> Cc: 
>
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Web Authorization Protocol WG of the IETF.
>
> Title   : Resource Indicators for OAuth 2.0
> Authors : Brian Campbell
>   John Bradley
>   Hannes Tschofenig
> Filename: draft-ietf-oauth-resource-indicators-06.txt
> Pages   : 14
> Date: 2019-09-05
>
> Abstract:
>This document specifies an extension to the OAuth 2.0 Authorization
>Framework defining request parameters that enable a client to
>explicitly signal to an authorization server about the identity of
>the protected resource(s) to which it is requesting access.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-06
>
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-resource-indicators-06
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-resource-indicators-06
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> ___
> 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-WG] Fwd: I-D Action: draft-ietf-oauth-resource-indicators-06.txt

[Brian Campbell]

-06 should address comments from IESG evaluation

-- Forwarded message -
From: 
Date: Thu, Sep 5, 2019 at 12:45 PM
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-resource-indicators-06.txt
To: 
Cc: 



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

Title   : Resource Indicators for OAuth 2.0
Authors : Brian Campbell
  John Bradley
  Hannes Tschofenig
Filename: draft-ietf-oauth-resource-indicators-06.txt
Pages   : 14
Date: 2019-09-05

Abstract:
   This document specifies an extension to the OAuth 2.0 Authorization
   Framework defining request parameters that enable a client to
   explicitly signal to an authorization server about the identity of
   the protected resource(s) to which it is requesting access.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-06
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-resource-indicators-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-resource-indicators-06


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

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

___
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] Benjamin Kaduk's No Objection on draft-ietf-oauth-resource-indicators-05: (with COMMENT)

[Brian Campbell]

thanks and done

On Thu, Sep 5, 2019 at 11:53 AM Benjamin Kaduk  wrote:

> On Wed, Sep 04, 2019 at 06:17:32PM -0600, Brian Campbell wrote:
> > On Wed, Sep 4, 2019 at 5:55 PM Benjamin Kaduk  wrote:
> >
> > > On Wed, Sep 04, 2019 at 05:19:27PM -0600, Brian Campbell wrote:
> > > > Thanks Ben, for the review and non-objectional ballot.
> > > >
> > > > On Wed, Sep 4, 2019 at 3:13 PM Benjamin Kaduk via Datatracker <
> > > > nore...@ietf.org> wrote:
> > > >
> > > > > Benjamin Kaduk has entered the following ballot position for
> > > > > draft-ietf-oauth-resource-indicators-05: No Objection
> > > > >
> > > > > Section 3
> > > > >
> > > > >An access token that is audience restricted to a protected
> resource
> > > > >that obtains that token legitimately cannot be used to access
> > > > >resources on behalf of the resource owner at other protected
> > > > >resources.  The "resource" parameter enables a client to
> indicate
> > > the
> > > > >
> > > > > nit: This sentence has a pretty strange construction.  I think the
> > > > > intent is to say that that a token, legitimately presented to a
> > > > > resource, cannot then be taken by that resource server and
> > > > > illegitimately present it somewhere else for access to other
> resources.
> > > > > But with the current wording we seem to be missing part of the part
> > > > > where some entity obtains the token with intent for illegitimate
> > > access.
> > > > >
> > > >
> > > > Yes, despite the pretty strange construction, you have the correct
> > > intent.
> > > > I'll work on improving that sentence (borrowing heavily from your
> words
> > > > there).
> > > >
> > > >
> > > >
> > > > >Some servers may host user content or be multi-tenant.  In
> order to
> > > > >avoid attacks that might confuse a client into sending an access
> > > > >token to a resource that is user controlled or is owned by a
> > > > >different tenant, it is important to use a specific resource URI
> > > > >including a path component.  This will cause any access token
> issued
> > > > >for accessing the user controlled resource to have an invalid
> > > > >audience if replayed against the legitimate resource API.
> > > > >
> > > > > I'm not entirely sure what this is trying to say.  What is the
> > > > > "legitimate resource API"?  Why would a token be issued for
> accessing a
> > > > > user-controlled resource if that's something we're trying to avoid
> > > > > having confused clients access?
> > > > >
> > > >
> > > > Um... so on rereading that I might say that it's also "pretty
> strange".
> > > >
> > > > What it was trying to somehow say is similar to the previous nit
> about
> > > > audience-restricted not being usable at the resource for whom the
> weren't
> > > > intended. But saying so in the context of a multi-tenant environment.
> > > > Basically it's trying to say that, in a multi-tenant environment, the
> > > > resource URI and subsequent token audience need to have something
> that
> > > > identifies the tenant so as to prevent the token from being used by
> one
> > > > tenant to illegitimately access resources at a different tenant. I'll
> > > work
> > > > on trying to improve that text to better explain all that.
> > >
> > > Ah, yes, that's a very good point to make.  I'm happy to look at some
> draft
> > > text if you want.
> > >
> >
> > Thanks, here's what I've got now for this and the previous item in sec 3.
> > Suggestions welcome.
> >
> > 3.  Security Considerations
> >
> >An audience-restricted access token, legitimately presented to a
> >resource, cannot then be taken by that resource to present it
> >elsewhere for illegitimate access to other resources.  The "resource"
>
> I think "by that resource and presented elsewhere" probbaly has a more
> parallel flow.
>
> >parameter enables a client to indicate the protected resources where
> >the requested access token will be use

Re: [OAUTH-WG] Benjamin Kaduk's No Objection on draft-ietf-oauth-resource-indicators-05: (with COMMENT)

[Brian Campbell]

On Wed, Sep 4, 2019 at 5:55 PM Benjamin Kaduk  wrote:

> On Wed, Sep 04, 2019 at 05:19:27PM -0600, Brian Campbell wrote:
> > Thanks Ben, for the review and non-objectional ballot.
> >
> > On Wed, Sep 4, 2019 at 3:13 PM Benjamin Kaduk via Datatracker <
> > nore...@ietf.org> wrote:
> >
> > > Benjamin Kaduk has entered the following ballot position for
> > > draft-ietf-oauth-resource-indicators-05: No Objection
> > >
> > > Section 3
> > >
> > >An access token that is audience restricted to a protected resource
> > >that obtains that token legitimately cannot be used to access
> > >resources on behalf of the resource owner at other protected
> > >resources.  The "resource" parameter enables a client to indicate
> the
> > >
> > > nit: This sentence has a pretty strange construction.  I think the
> > > intent is to say that that a token, legitimately presented to a
> > > resource, cannot then be taken by that resource server and
> > > illegitimately present it somewhere else for access to other resources.
> > > But with the current wording we seem to be missing part of the part
> > > where some entity obtains the token with intent for illegitimate
> access.
> > >
> >
> > Yes, despite the pretty strange construction, you have the correct
> intent.
> > I'll work on improving that sentence (borrowing heavily from your words
> > there).
> >
> >
> >
> > >Some servers may host user content or be multi-tenant.  In order to
> > >avoid attacks that might confuse a client into sending an access
> > >token to a resource that is user controlled or is owned by a
> > >different tenant, it is important to use a specific resource URI
> > >including a path component.  This will cause any access token issued
> > >for accessing the user controlled resource to have an invalid
> > >audience if replayed against the legitimate resource API.
> > >
> > > I'm not entirely sure what this is trying to say.  What is the
> > > "legitimate resource API"?  Why would a token be issued for accessing a
> > > user-controlled resource if that's something we're trying to avoid
> > > having confused clients access?
> > >
> >
> > Um... so on rereading that I might say that it's also "pretty strange".
> >
> > What it was trying to somehow say is similar to the previous nit about
> > audience-restricted not being usable at the resource for whom the weren't
> > intended. But saying so in the context of a multi-tenant environment.
> > Basically it's trying to say that, in a multi-tenant environment, the
> > resource URI and subsequent token audience need to have something that
> > identifies the tenant so as to prevent the token from being used by one
> > tenant to illegitimately access resources at a different tenant. I'll
> work
> > on trying to improve that text to better explain all that.
>
> Ah, yes, that's a very good point to make.  I'm happy to look at some draft
> text if you want.
>

Thanks, here's what I've got now for this and the previous item in sec 3.
Suggestions welcome.

3.  Security Considerations

   An audience-restricted access token, legitimately presented to a
   resource, cannot then be taken by that resource to present it
   elsewhere for illegitimate access to other resources.  The "resource"
   parameter enables a client to indicate the protected resources where
   the requested access token will be used, which in turn enables the
   authorization server to apply the appropriate audience restrictions
   to the token.

   Some servers may host user content or be multi-tenant.  In order to
   avoid attacks where one tenant uses an access token to illegitimately
   access resources owned by a different tenant, it is important to use
   a specific resource URI including any portion of the URI that
   identifies the tenant, such as a path component.  This will allow
   access tokens to be audience-restricted in a way that identifies the
   tenant and prevent their use, due to an invalid audience, at
   resources owned by a different tenant.

-- 
_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] Benjamin Kaduk's No Objection on draft-ietf-oauth-resource-indicators-05: (with COMMENT)

[Brian Campbell]

Thanks Ben, for the review and non-objectional ballot.

On Wed, Sep 4, 2019 at 3:13 PM Benjamin Kaduk via Datatracker <
nore...@ietf.org> wrote:

> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-oauth-resource-indicators-05: No Objection

--
> COMMENT:
> --
>
> Abstract
>
> This seems to be a sentence fragment (maybe preface with "This document
> specifies"?).
>

Hrm. Yeah, I suppose so. I guess I was trying to be efficient with the
words but to the point of not having a complete sentence. I'll add that
preface.



> Section 2.1
>
>For authorization requests sent as a JWTs, such as when using JWT
>Secured Authorization Request [I-D.ietf-oauth-jwsreq], a single
>"resource" parameter value is represented as a JSON string while
>multiple values are represented as an array of strings.
>
> jwsreq includes an example with "aud" in the request, yet this new
> "resource" request parameter is also intended to influence the audience
> of the resulting token.  I'm not sure whether we need to say anything
> specifically about this in the document, but I'd like to have a better
> understanding of how "aud" and "resource" would interact when both
> present in the reqeust.
> (This is presumably related to why the request parameter is called
> "resource" and not "aud" or "audience", but unfortunately I seem to have
> zoned out for that part of the WG discussion.)
>

In the context of a jwsreq request the "aud" indicates the intended
recipient/audience of the singed authorization request itself, which will
be the authorization server to whom the request is being made. This
prevents a singed request meant for AS1 from being used successfully at
AS2, for example. That "aud" does not do anything to influence the audience
of the resulting token - it's really just metadata of the signed request
that will be discarded once the singed request is validated. The "resource"
parameter of this document indicates where the client intends to use the
token its requesting, which can and will influence the audience of the
resulting token. So "aud" and "resource" do not interact when both present
in a signed authorization request.

And yes, this is related to why the request parameter is called "resource"
and not "aud" and also I think related to the outstanding discuss you have
on jwsreq. If this parameter were to have been called "aud" then there
would be a name collision when used in conjunction with jwsreq where "aud"
would have had two distinct and irreconcilable meanings at the same time.
There are a few other reasons the WG landed on "resource" as the name but
what you've alluded to up here was a big part of it.



   If the client omits the "resource" parameter when requesting
>authorization, the authorization server MAY process the request with
>no specific resource or by using a pre-defined default resource
>value.  [...]
>
> Would/could this default value be global or on a per-scope basis or some
> other finer granularity than global?
>

Yes, it could be any of those. Though I think most likely it'd be global or
influenced by scope. Really, it'd be whatever that AS was doing in the
absence of such a parameter before this document came along.



>  The
>authorization server might use this data to inform the user about the
>resources the client is going to access on her behalf, to meet policy
>decision (e.g. refuse the request due to unknown resources), and
>determine the set of resources that can be used in subsequent access
>token requests.
>
> nits: comma after "e.g.", and maybe s/meet policy decision/apply policy/
> (or similar), and "to" before "determine" for parallelism.
>

Okay, will do.



> In Figure 1 we URL-encode the '.'s in "client.example.org" but not in
> "api.example.com" in the request URL; should we be consistent?  (This
> seems to be recurring throughout the examples.)
>

Shoot. I really do aim to be tighter with that kind of thing well before
getting to the IESG evaluation phase. I suspect some copy/paste/change work
along with not looking closely enough got the better of me here. I'll fix
to use not-encoded '.'s throughout.



> Section 2.2
>
>needs to know.  This further improves privacy as scope values give an
>indication of what services the resource owner uses and downscoping a
>token to only that which is needed for a particular service can limit
>the extent to which such information is revealed across different
>services.  As specified in Section 5.1 of [RFC6749], the
>
> (nit?) I suggest to s/scope values give an indication of what services
> the resource owner uses and/a list of scope values is an indication that
> the
> resource owner uses the multiple various services listed;/ since I
> misparsed it the fir

Re: [OAUTH-WG] Adam Roach's No Objection on draft-ietf-oauth-resource-indicators-05: (with COMMENT)

[Brian Campbell]

Thanks Barry, I kinda like it. Although I'm a bit hesitant to make a change
like that at this stage. I guess I'd be looking for a little more buy-in
from folks first. Though it's not actually a functional breaking change. So
maybe okay to just go with.

On Wed, Sep 4, 2019 at 2:54 PM Barry Leiba  wrote:

> > Yeah, with query parameters lacking the hierarchical semantics that the
> path component has, it is much less clear. In fact, an earlier revision of
> the draft forbid the query part as I was trying to avoid the ambiguity that
> it brings. But there were enough folks with some use case for it that it
> made its way back in. While I am sympathetic to the point you're making
> here, I'd prefer to not codify the practice any further by way of example
> in the document.
>
> Is it perhaps reasonable to discourage the use of a query component
> while still allowing it?  Maybe a "SHOULD NOT", such as this?:
>
> OLD
>   Its value MUST be an absolute URI, as specified by
>   Section 4.3 of [RFC3986], which MAY include a query component but
>   MUST NOT include a fragment component.
> NEW
>   Its value MUST be an absolute URI, as specified by
>   Section 4.3 of [RFC3986].  The URI MUST NOT include
>   a fragment component.  It SHOULD NOT include a query
>   component, but it is recognized that there are cases that
>   make a query component useful.
> END
>
> What do you think?
>
> Barry
>

-- 
_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] Adam Roach's No Objection on draft-ietf-oauth-resource-indicators-05: (with COMMENT)

[Brian Campbell]

Thanks Adam, for the review and No Objection ballot.

On Wed, Sep 4, 2019 at 12:07 AM Adam Roach via Datatracker 
wrote:

> Adam Roach has entered the following ballot position for
> draft-ietf-oauth-resource-indicators-05: No Objection
>
> --
> COMMENT:
> --
>
> Many thanks to everyone who worked on this refinement to OAuth.
> It seems like it will be a significant improvement over today's
> ad-hoc system.
>
> I agree with Barry and Alexey about the need for some language discussing
> the privacy implications of explicitly signaling audience resources to
> OAuth servers.
>

Barry had other nits and was looking for some clarifying hyphenation. While
it was Alexey, Mirja, Alissa and Eric who have expressed the desire to see
some discussion of the privacy implications added. But I digress and the
who doesn't much matter as the need for something seems to have been
clearly established via comment by a few folks. I've been working on some
text towards that end. Honestly, I'm not too thrilled with it - it amounts
to saying that there's already not much privacy in OAuth and explicitly
signaling resources might make the situation only marginally worse - not
sure what else to say but I do plan to put some text along those lines
discussing the privacy implications in for the next revision.


§2:
>
> >  The client SHOULD use the base URI of the API
> >  as the "resource" parameter value unless specific knowledge of the
> >  resource dictates otherwise.  For example, the value
> >  "https://api.example.com/"; would be used for a resource that is the
> >  exclusive application on that host, however, if the resource is one
> >  of many applications on that host, something like
> >  "https://api.example.com/app/"; would be used as a more specific
> >  value.  Another example, for an API like SCIM [RFC7644] that has
> >  multiple endpoints such as "https://apps.example.com/scim/Users";,
> >  "https://apps.example.com/scim/Groups";, and
> >  "https://apps.example.com/scim/Schemas"; The client would use
> >  "https://apps.example.com/scim/"; as the resource so that the issued
> >  access token is valid for all the endpoints of the SCIM API.
>
> This seems pretty intuitive in the examples given. It may be a little
> less clear when applications are indicated by query parameter instead
> of path prefixes. For example, if an endpoint is running two applications
> distinguished thus:
>
> https://example.com/apps/?app=app1
> https://example.com/apps/?app=app2
>
> ...and in a form that allows for additional parameters:
>
> https://example.com/apps/?darkmode=true&version=1.2&app=app2
>
> ...then the notion of the "most specific API" isn't quite as clear.
> Intuitively, I think the idea would be that the resource for app2
> would be . It may be useful
> to include an example along these lines as an illustration.
>

Yeah, with query parameters lacking the hierarchical semantics that the
path component has, it is much less clear. In fact, an earlier revision of
the draft forbid the query part as I was trying to avoid the ambiguity that
it brings. But there were enough folks with some use case for it that it
made its way back in. While I am sympathetic to the point you're making
here, I'd prefer to not codify the practice any further by way of example
in the document.



§2.2:
>
> >&resource=https%3A%2F%2Fcontacts.example.com%2Fapp%2F
> ...
> >"access_token":"eyJhbGciOiJFUzI1NiIsImtpZCI6Ijc3In0.eyJpc3MiOi
> > JodHRwOi8vYXV0aG9yaXphdGlvbi1zZXJ2ZXIuZXhhbXBsZS5jb20iLCJzdWI
> > iOiJfX2JfYyIsImV4cCI6MTU4ODQyMDgyNiwic2NvcGUiOiJjb250YWN0cyIs
> > ImF1ZCI6Imh0dHBzOi8vY29udGFjdHMuZXhhbXBsZS5jb20vIn0.5f4yhqazc
> > OSlJw4y94KPeWNEFQqj2cfeO8x4hr3YbHtIl3nQXnBMw5wREY5O1YbZED-GfH
> > UowfmtNaA5EikYAw",
>
> The "aud" value here is "https://contacts.example.com/"; rather than the
> "https://contacts.example.com/app/"; that I would expect -- that is, I
> would
> expect them to match. Am I misunderstanding the intended relationship
> between
> "resouce" and "aud"?
>

The relationship doesn't necessarily have to be 1-1 (text about that at the
very end of the main sec 2) but I think here I've just messed up the
example a bit. Looking again at series of examples that kinda build on one
another as well as the explanatory text leading up to figures 5 & 6, it
seems that the value of the resource in the request in figure 5 probably
should have also been just "https://contacts.example.com/"; without the
extraneous path part. And that would then match up to your expectations of
the aud claim in figure 6. I'll change figure 5 accordingly to fix that.


§3:
>
> >  Some servers may host user content or be multi-tenant.  In order to
> >  avoid attacks that might confuse a client into sending an access
> >  token to a resource that is user control

Re: [OAUTH-WG] [Gen-art] Genart last call review of draft-ietf-oauth-resource-indicators-05

[Brian Campbell]

Thanks Alissa!

On Wed, Sep 4, 2019 at 8:36 AM Alissa Cooper  wrote:

> Stewart, thanks for your review. Brian, thanks for the fix. I’ve entered a
> No Objection ballot.
>
> Regards,
> Alissa
>
> On Aug 13, 2019, at 2:43 PM, Brian Campbell <
> bcampbell=40pingidentity@dmarc.ietf.org> wrote:
>
> Thanks for the review Stewart and my apologies for the slow response - I
> left on a longish summer family vacation the day before the review email
> hit my inbox.
>
> I've fixed the nit by using "JSON Web Token (JWT)" on that first use in
> the source controlled editor's xml version and it'll show up in the next
> draft revision.
>
>
> On Tue, Jul 30, 2019 at 11:35 AM Stewart Bryant via Datatracker <
> nore...@ietf.org> wrote:
>
>> Reviewer: Stewart Bryant
>> Review result: Ready
>>
>> 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
>>
>> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>>
>> Document: draft-ietf-oauth-resource-indicators-05
>> Reviewer: Stewart Bryant
>> Review Date: 2019-07-30
>> IETF LC End Date: 2019-08-05
>> IESG Telechat date: Not scheduled for a telechat
>>
>> Summary: A well written document ready for publication.  It has one very
>> minor
>> nit that needs to be addressed at some point.
>>
>> Major issues: None
>>
>> Minor issues: None
>>
>> Nits/editorial comments:  JWT is not in the well known list and does not
>> seem
>> to be expanded on first use,
>>
>>
>>
> *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.*___
> Gen-art mailing list
> gen-...@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art
>
>
>

-- 
_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] Barry Leiba's No Objection on draft-ietf-oauth-resource-indicators-05: (with COMMENT)

[Brian Campbell]

Barry, thanks for the review and ballot position.

On Tue, Sep 3, 2019 at 1:34 PM Barry Leiba via Datatracker 
wrote:

> Barry Leiba has entered the following ballot position for
> draft-ietf-oauth-resource-indicators-05: No Objection
>
> --
> COMMENT:
> --
>
> -- Section 2 --
>
>invalid_target
>   The requested resource is invalid, unknown, or malformed.
>
> For clarity, I suggest adding "missing" to the list, as specified in
> Section
> 2.1, '...and MAY fail requests that omit the parameter with an
> "invalid_target"
> error.'
>
>The authorization server SHOULD audience restrict issued access
>tokens to the resource(s) indicated by the "resource" parameter.
>

Makes sense, will do.



> I can't parse this sentence.  I see "audience" as a verb, and don't
> understand.
> AH.  I read later in the document and figured out my problem: I think it
> would
> help if you hyphenate "audience-restrict" (and "audience-restricted"
> later).
> No?
>

Yes? Short of Adam Roach stepping in here to teach me more about proper use
of hyphens [1], I think that would be helpful and will make the changes.


[1] https://mailarchive.ietf.org/arch/msg/oauth/IsoOa0jvabolUSzjzWHjk8b0aVY

-- 
_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] Éric Vyncke's No Objection on draft-ietf-oauth-resource-indicators-05: (with COMMENT)

[Brian Campbell]

Thank you, Éric, for the review and ballot position.


On Mon, Sep 2, 2019 at 3:40 AM Éric Vyncke via Datatracker 
wrote:

> Éric Vyncke has entered the following ballot position for
> draft-ietf-oauth-resource-indicators-05: No Objection

--
> COMMENT:
> --
>
> Thank you for the hard work put into this easy to read document.
>

Thanks, I'm happy to hear that you found it readable.



> == COMMENTS ==
>
> -- Section 1 --
> "has uncovered a need, in some circumstances" (and similar sentences in
> section
> 1), it is rather vague for a standard track document... Please add some
> facts
> and data, this could be a companion document about requirements/use cases..
>

Sec 1 is intended to be a general (though not vague) introduction with some
explanation about what an authorization server might be able to accomplish
with an understanding of the location/identity of the protected resource
for which the client is requesting an access token. Which effectively boils
down to being able to produce the token appropriate for the indicated
resource (including the type of token, if and how it's encrypted, what
information is contained or referenced, to whom it is audience restricted).
I've no doubt that the writing could stand to be improved (which is always
the case with content I've written) but those are the use cases and I don't
have more specific facts or data.



>
> -- Section 2 --
> It is rather a question of mine, why does the resource need to be a URI
> (which
> usually bears some visible semantics) rather than an opaque string known
> only
> by the resource owner/server ? This is similar to Mirja's comment about
> privacy.
>

The motivation behind the draft is largely to facilitate this explicit
signal to the authorization server (AS) about the location or identity of
the protected resource for which the client is requesting an access token.
For the reasons previously mentioned. Something that's opaque to the AS
would negate the ability of the AS to do most of that stuff (admittedly not
all but most).

-- 
_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] JWT Secured Authorization Request (JAR) vs OIDC request object

[Brian Campbell]

FWIW, as best I can remember the change in question came as I result
of directorate/IESG
review rather than a WG decision/discussion. Which is likely why you can't
find the "why" anywhere in the mailing list archive.

On Wed, Aug 28, 2019 at 3:23 PM Filip Skokan  wrote:

> Well it kind of blows, doesn't it? I wasn't able to find the "why"
> anywhere in the mailing list archive around the time this was changed.
>
> My take on satisfying both worlds looks like this
>
> - allow just JAR - no other params when possible.
> (which btw isn't possible to do with request_uri when enforcing client
> based uri whitelist and the jwsreq 5.2.2 shows as much)
> - enforce the "dupe behaviours" defined in OIDC (if response_type or
> client_id is in request object it must either be missing or the same in
> regular request).
> - allows merging request object and regular parameters with request object
> taking precedence since it is a very useful feature when having pre-signed
> request object that's not one time use and clients using it wish to vary
> state/nonce per-request.
>
> I wish the group reconsidered making this breaking change from OIDC's take
> on request objects - allow combination of parameters from the request
> object with ones from regular parameters (if not present in request object).
>
> S pozdravem,
> *Filip Skokan*
>
>
> On Wed, 28 Aug 2019 at 23:02, Brian Campbell 
> wrote:
>
>> Filip, for better or worse, I believe your assessment of the situation is
>> correct. I know of one AS that didn't choose which of the two to follow but
>> rather implemented a bit of a hybrid where it basically ignores everything
>> outside of the request object per JAR but also checks for and enforces the
>> presence and value of the few regular parameters (client_id, response_type)
>> that OIDC mandates.
>>
>> On Tue, Aug 27, 2019 at 5:47 AM Filip Skokan  wrote:
>>
>>> Hello everyone,
>>>
>>> in an earlier thread I've posed the following question that might have
>>> gotten missed, this might have consequences for the existing
>>> implementations of Request Objects in OIDC implementations - its making
>>> pure JAR requests incompatible with OIDC Core implementations.
>>>
>>> draft 14 of jwsreq (JAR) introduced this language
>>>
>>> The client MAY send the parameters included in the request object
>>>> duplicated in the query parameters as well for the backward
>>>> compatibility etc.
>>>>
>>>> *However, the authorization server supporting thisspecification MUST
>>>> only use the parameters included in the requestobject. *
>>>
>>>
>>> Server MUST only use the parameters in the Request Object even if the
>>>> same parameter is provided in the query parameter.  The Authorization
>>>
>>>
>>> The client MAY send the parameters included in the request object
>>>> duplicated in the query parameters as well for the backward
>>>> compatibility etc.
>>>>
>>>> *However, the authorization server supporting thisspecification MUST
>>>> only use the parameters included in the requestobject. *
>>>
>>>
>>> Nat, John, everyone - *does this mean a JAR compliant AS ignores
>>> everything outside of the request object while OIDC Request Object one
>>> merges the two with the ones in the request object being used over ones
>>> that are sent in clear?* The OIDC language also includes sections which
>>> make sure that some required arguments are still passed outside of the
>>> request object with the same value to make sure the request is "valid"
>>> OAuth 2.0 request (client_id, response_type), something which an example in
>>> the JAR spec does not do. Not having this language means that existing
>>> authorization request pipelines can't simply be extended with e.g. a
>>> middleware, they need to branch their codepaths.
>>>
>>> Is an AS required to choose which of the two it follows?
>>>
>>> Thank you for clarifying this in advance. I think if either the
>>> behaviour is the same as in OIDC or different this should be called out in
>>> the language to avoid confusion, especially since this already exists in
>>> OIDC and likely isn't going to be read in isolation, especially because the
>>> Request Object is even called out to be already in place in OIDC in the JAR
>>> draft.
>>>
>>> Best,
>>> *Filip*
>>> 

Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object

[Brian Campbell]

Filip, for better or worse, I believe your assessment of the situation is
correct. I know of one AS that didn't choose which of the two to follow but
rather implemented a bit of a hybrid where it basically ignores everything
outside of the request object per JAR but also checks for and enforces the
presence and value of the few regular parameters (client_id, response_type)
that OIDC mandates.

On Tue, Aug 27, 2019 at 5:47 AM Filip Skokan  wrote:

> Hello everyone,
>
> in an earlier thread I've posed the following question that might have
> gotten missed, this might have consequences for the existing
> implementations of Request Objects in OIDC implementations - its making
> pure JAR requests incompatible with OIDC Core implementations.
>
> draft 14 of jwsreq (JAR) introduced this language
>
> The client MAY send the parameters included in the request object
>> duplicated in the query parameters as well for the backward
>> compatibility etc.
>>
>> *However, the authorization server supporting thisspecification MUST only
>> use the parameters included in the requestobject. *
>
>
> Server MUST only use the parameters in the Request Object even if the
>> same parameter is provided in the query parameter.  The Authorization
>
>
> The client MAY send the parameters included in the request object
>> duplicated in the query parameters as well for the backward
>> compatibility etc.
>>
>> *However, the authorization server supporting thisspecification MUST only
>> use the parameters included in the requestobject. *
>
>
> Nat, John, everyone - *does this mean a JAR compliant AS ignores
> everything outside of the request object while OIDC Request Object one
> merges the two with the ones in the request object being used over ones
> that are sent in clear?* The OIDC language also includes sections which
> make sure that some required arguments are still passed outside of the
> request object with the same value to make sure the request is "valid"
> OAuth 2.0 request (client_id, response_type), something which an example in
> the JAR spec does not do. Not having this language means that existing
> authorization request pipelines can't simply be extended with e.g. a
> middleware, they need to branch their codepaths.
>
> Is an AS required to choose which of the two it follows?
>
> Thank you for clarifying this in advance. I think if either the behaviour
> is the same as in OIDC or different this should be called out in the
> language to avoid confusion, especially since this already exists in OIDC
> and likely isn't going to be read in isolation, especially because the
> Request Object is even called out to be already in place in OIDC in the JAR
> draft.
>
> Best,
> *Filip*
> ___
> 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] Mirja Kühlewind's No Objection on draft-ietf-oauth-resource-indicators-05: (with COMMENT)

[Brian Campbell]

Thanks for the review and not objectionable ballot, Mirja.

I wasn't aware of Alexey's comment until I saw your message here and went
to the tracker
https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/ballot/
to find it. I think maybe an email got lost somewhere or didn't send or
something? Anyway, in an attempt at bringing some continuity to the
discussion I've copied his comment here:


"I like this document.

Is tracking by authorization server a concern? I suspect
on the balance it is less important than restricting token
scope (and thus improving security of bearer tokens), but
maybe this shoukd be mentioned in the Security Considerations."


In all honesty, tracking by authorization server hasn't been a concern in
my mind when working on this document because the authorization server is
already squarely in the middle of everything and able to track a
significant amount even in the absence of what this document describes.
And, as you mention, the potential to improve security in an already
track-able situation is more important in my mind. With that said, however,
I suppose that the resource parameter in this document does, in some
circumstances (like when token introspection is not being used), make
tracking things at a more granular and specific level possible. And that
might warrant a mention in the Security (or Privacy) Considerations. I'm
honestly not too sure what exactly that mention would say or how it would
say it but I can work on some text.




On Wed, Aug 28, 2019 at 6:57 AM Mirja Kühlewind via Datatracker <
nore...@ietf.org> wrote:

>
> --
> COMMENT:
> --
>
> I agree with Alexey that it would be good to mention any privacy
> implications
> of providing this additional information to the auth server in the security
> consideration section; maybe also further advising clients on which
> resources
> to request when.
>

-- 
_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] Suresh Krishnan's No Objection on draft-ietf-oauth-mtls-16: (with COMMENT)

[Brian Campbell]

Thanks again for the suggestion Suresh. The switch to use RFC5952 is now in
the document https://tools.ietf.org/html/draft-ietf-oauth-mtls-17




On Wed, Aug 21, 2019 at 3:51 PM Brian Campbell 
wrote:

> Thanks Suresh, I'll consider using RFC5952 there as I try and work though
> some other comments on that parameter in that section.
>
> On Tue, Aug 20, 2019 at 1:16 PM Suresh Krishnan via Datatracker <
> nore...@ietf.org> wrote:
>
>>
>> --
>> COMMENT:
>> --
>>
>> * Section 2.1.2.
>>
>> Suggest using the IPv6 Address Text Representation described in RFC5952
>> instead
>> of using the representations described in RFC4291 section 2.2. The
>> canonical
>> representation described in RFC5952 makes it easier to compare two IPv6
>> address
>> strings which is probably something you want to do while doing mutual
>> authentication.
>>
>>
>> ___
>> 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] Adam Roach's No Objection on draft-ietf-oauth-mtls-16: (with COMMENT)

[Brian Campbell]

Thanks again Adam for the review, suggestions, and grammar lesson. I went
ahead and pushed a -17, which I think addresses everything discussed
herein.

https://tools.ietf.org/html/draft-ietf-oauth-mtls-17


On Thu, Aug 22, 2019 at 5:02 PM Adam Roach  wrote:

> On 8/22/19 5:48 PM, Brian Campbell wrote:
> > Regarding the comment on tls_client_auth_san_ip, some other reviewers
> > have suggested using the using the IPv6 Address Text Representation
> > described in RFC 5952 rather than the one from in RFC 4291. Which I
> > think makes sense to do. Maybe also with a note that the comparison of
> > the addresses should done using binary as suggested in
> > https://tools.ietf.org/html/rfc5952#section-8
> >
> > What do you think?
>
>
> That sounds like a fine approach. Thanks for digging that reference up. :)
>
> /a
>
>

-- 
_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] Benjamin Kaduk's Discuss on draft-ietf-oauth-mtls-16: (with DISCUSS and COMMENT)

[Brian Campbell]

I went ahead and pushed a -17, which I think addresses everything discussed
in this thread.

https://tools.ietf.org/html/draft-ietf-oauth-mtls-17

Thanks again for the review and suggestions.

On Fri, Aug 23, 2019 at 3:07 PM Brian Campbell 
wrote:

> Thanks for the responses Ben. More inline below with stuff that warrants
> no further discussion snipped out.
>
> On Thu, Aug 22, 2019 at 5:17 PM Benjamin Kaduk  wrote:
>
>>
>>   But it's possible to be naive and be correct at the same time...
>>
>
> I rather like that and suspect I might have to use it in the future :)
>
>
>
>> In terms of proposed text, it looks like after the first paragraph of
>> Section 3 would be a reasonable place, perhaps:
>>
>> In order for a resource server to use certificate-bound access tokens, it
>> must have advance knowledge that mtls is to be used for some or all
>> resource accesses.  In particular, the client ID or access token itself
>> cannot be used as input to the decision of whether or not to use mtls,
>> since from the TLS perspective those are "Application Data", only
>> exchanged
>> after the TLS handshake has been completed, and the initial
>> CertificateRequest occurs during the handshake, before the Application
>> Data
>> is available.  Although subsequent opportunities for a TLS client to
>> present a certificate may be available, e.g., via TLS 1.2 renegotiation
>> [RFC5246] or TLS 1.3 post-handshake authentication [RFC8446], this
>> document
>> makes no provision for their usage.  It is expected to be common that a
>> mtls-using resource server will require mtls for all resources hosted
>> thereupon, or will serve mtls-protected and regular resources on separate
>> hostname+port combinations, though other workflows are possible.  How
>> resource server policy is synchronized with the AS is out of scope for
>> this
>> document.
>>
>> And then the following paragraph could start "Within the scope of an
>> mtls-protected resource-access flow,"
>>
>
> Thank you for that. Super helpful. I'll incorporate.
>
>
> > And my intent and assumption was that a mismatch covered the case where
>> no
>> > certificate was presented (i.e. null cert doesn't match expected cert
>> just
>> > as different cert doesn't match). But perhaps that particular case
>> should
>> > be made more explicit?  The second to last paragraph of sec 3
>>
>> It probably should; "if the presented certificate" as a predicate could
>> fairly be easily read as to ignore the case where no certificate is
>> presented.
>>
>
> Fair enough. Maybe, "If no certificate is presented or that which is
> presented doesn't match" would suffice to avoid that reading?
>
>
> > https://tools.ietf.org/html/draft-ietf-oauth-mtls-16#section-3 has
>> similar
>> > guidance for error handing in the case of mismatch during resource
>> access.
>> >
>> > The case of a so called public client that has
>> > tls_client_certificate_bound_access_tokens metadata of true that shows
>> up
>> > at the token endpoint without having done MTLS is a bit more nuanced
>> and I
>> > think it's untimely a policy decision for the AS at that point as to
>> > whether to error or issue an unbound token.
>>
>> Do you have any feelings about whether or not you want to mention that
>> case
>> explicitly as being up to local policy at the AS (vs. leaving it implicit
>> as is presently being done)?
>>
>
> I don't really *want* to add anything but it's probably better to be
> explicit about it. I'll look for a place to work it in.
>
>
>
>>
>> > I am not *nix skilled enough to troubleshoot that command pipeline but I
>> > suspect that the sha256sum output is in hex which represents each byte
>> of
>> > the hash output with two charterers and thus double the resultant size..
>>
>> Please excuse me while I wipe the egg off my face.
>> Yes, that sha256sum output is in hex, and I should have counted the bits
>> directly.  I hope you did not waste too much time on this (and now I can
>> get the thumbprint to agree).
>>
>
> No worries. I only spent enough time second guessing everything so as to
> try and avoid getting egg on my own face.
>
>
>
>> > > --
>> > > COMMENT:
>> > > --
>> > >
>> > 

Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-mtls-16: (with DISCUSS and COMMENT)

[Brian Campbell]

Thanks for the responses Ben. More inline below with stuff that warrants no
further discussion snipped out.

On Thu, Aug 22, 2019 at 5:17 PM Benjamin Kaduk  wrote:

>
>   But it's possible to be naive and be correct at the same time...
>

I rather like that and suspect I might have to use it in the future :)



> In terms of proposed text, it looks like after the first paragraph of
> Section 3 would be a reasonable place, perhaps:
>
> In order for a resource server to use certificate-bound access tokens, it
> must have advance knowledge that mtls is to be used for some or all
> resource accesses.  In particular, the client ID or access token itself
> cannot be used as input to the decision of whether or not to use mtls,
> since from the TLS perspective those are "Application Data", only exchanged
> after the TLS handshake has been completed, and the initial
> CertificateRequest occurs during the handshake, before the Application Data
> is available.  Although subsequent opportunities for a TLS client to
> present a certificate may be available, e.g., via TLS 1.2 renegotiation
> [RFC5246] or TLS 1.3 post-handshake authentication [RFC8446], this document
> makes no provision for their usage.  It is expected to be common that a
> mtls-using resource server will require mtls for all resources hosted
> thereupon, or will serve mtls-protected and regular resources on separate
> hostname+port combinations, though other workflows are possible.  How
> resource server policy is synchronized with the AS is out of scope for this
> document.
>
> And then the following paragraph could start "Within the scope of an
> mtls-protected resource-access flow,"
>

Thank you for that. Super helpful. I'll incorporate.


> And my intent and assumption was that a mismatch covered the case where no
> > certificate was presented (i.e. null cert doesn't match expected cert
> just
> > as different cert doesn't match). But perhaps that particular case should
> > be made more explicit?  The second to last paragraph of sec 3
>
> It probably should; "if the presented certificate" as a predicate could
> fairly be easily read as to ignore the case where no certificate is
> presented.
>

Fair enough. Maybe, "If no certificate is presented or that which is
presented doesn't match" would suffice to avoid that reading?


> https://tools.ietf.org/html/draft-ietf-oauth-mtls-16#section-3 has similar
> > guidance for error handing in the case of mismatch during resource
> access.
> >
> > The case of a so called public client that has
> > tls_client_certificate_bound_access_tokens metadata of true that shows up
> > at the token endpoint without having done MTLS is a bit more nuanced and
> I
> > think it's untimely a policy decision for the AS at that point as to
> > whether to error or issue an unbound token.
>
> Do you have any feelings about whether or not you want to mention that case
> explicitly as being up to local policy at the AS (vs. leaving it implicit
> as is presently being done)?
>

I don't really *want* to add anything but it's probably better to be
explicit about it. I'll look for a place to work it in.



>
> > I am not *nix skilled enough to troubleshoot that command pipeline but I
> > suspect that the sha256sum output is in hex which represents each byte of
> > the hash output with two charterers and thus double the resultant size.
>
> Please excuse me while I wipe the egg off my face.
> Yes, that sha256sum output is in hex, and I should have counted the bits
> directly.  I hope you did not waste too much time on this (and now I can
> get the thumbprint to agree).
>

No worries. I only spent enough time second guessing everything so as to
try and avoid getting egg on my own face.



> > > --
> > > COMMENT:
> > > --
> > >
> > >protected resource access in step (B) is only possible by the
> > >legitimate client bearing the access token and holding the private
> > >key corresponding to the certificate.
> > >
> > > nit: I guess it is only protected resource access "using this tokwn"
> > > that is only possible as specified.
> > >
> >
> > I kinda felt like that was implied at this point. But I can add "using
> this
> > token" there, if you think it's needed or helpful?
>
> Or perhaps "using a certificate-bound token".  I think it's just barely
> worth adding, since this section is largely reiterating the general OAuth
> flow, and this helps emphasize that the "and holding the private key" is
> the important/new part.
>

Works for me.


> It's gotta be done (unless using the self-singed method) and it is
> > definitely up to deployments as I wouldn't even pretend to know where to
> > begin on providing general guidance nor would I think it appropriate.
> >
> > I felt like this was pretty well implied and touched on in security
> > considerations too. But please suggest some specific text, if y

Re: [OAUTH-WG] Adam Roach's No Objection on draft-ietf-oauth-mtls-16: (with COMMENT)

[Brian Campbell]

Regarding the comment on tls_client_auth_san_ip, some other reviewers have
suggested using the using the IPv6 Address Text Representation described in
RFC 5952 rather than the one from in RFC 4291. Which I think makes sense to
do. Maybe also with a note that the comparison of the addresses should done
using binary as suggested in https://tools.ietf.org/html/rfc5952#section-8

What do you think?

On Wed, Aug 21, 2019 at 4:07 PM Brian Campbell 
wrote:

> Thanks Adam, I attempt to provide not-too-terrible replies to your
> comments inline below.
>
> On Mon, Aug 19, 2019 at 8:02 PM Adam Roach via Datatracker <
> nore...@ietf.org> wrote:
>
>> --
>> COMMENT:
>> --
>>
>>
>> Thanks for the work that everyone did on this document. I have one
>> suggestion
>> for clarification, followed by a handful of editorial nits.
>>
>>
>> ---
>>
>> §2.1.2:
>>
>> >  tls_client_auth_san_ip
>> > A string representation of an IP address in either dotted decimal
>> > notation (for IPv4) or colon-delimited hexadecimal (for IPv6, as
>> > defined in [RFC4291] section 2.2) that is expected to be present
>> > as an iPAddress SAN entry in the certificate, which the OAuth
>> > client will use in mutual TLS authentication.
>>
>> This probably needs some text that clarifies expectations around
>> comparison
>> and/or normalization. For example, if the iPAddress value in the cert is
>> "20 01 0d b8 00 00 00 00 00 00 00 00 c0 00 02 ca" (and a mask of all
>> F's), one
>> should presume that this would match both tls_client_auth_san_ip values
>> "2001:db8:0:0:0:0:c000:2ca" and "2001:DB8::192.0.2.202", right? If no,
>> then
>> this document needs to talk about normalization of address representation.
>>
>
> Can you help me with some text here? I'm a bit out of my realm, to be
> honest. I naively just want it to say that the tls_client_auth_san_ip value
> and iPAddress value in the cert need to be the same IP address. But I do
> realize "same" isn't totally clear as your comment and others have pointed
> out. But I don't know enough to know how to write it in a way that's
> suitable for this kind of thing.
>
> Alternatively, as I mentioned in my response to Ben (down a ways in
> https://mailarchive.ietf.org/arch/msg/oauth/TMaNYXJgZ3-kz4GNsIL4O-9ncgQ),
> I've never personally been able to think of a situation where
> tls_client_auth_san_ip is actually needed.  So maybe removing it all
> together is an option as well?
>
>
>
>>
>> ---
>>
>> §1:
>>
>> >  Layering on the abstract flow above, this document standardizes
>> >  enhanced security options for OAuth 2.0 utilizing client certificate
>> >  based mutual TLS.
>>
>> Nit: "client-certificate-based"
>>
>
> Mr. Kaduk beat you to this one. Will fix.
>
>
> >  OAuth 2.0 defines a shared secret method of client authentication but
>>
>> Nit: "shared-secret"
>>
>
> Will fix.
>
>
>>
>>
>> ---
>> §1:
>>
>> >  This document describes an additional
>> >  mechanism of client authentication utilizing mutual TLS certificate-
>> >  based authentication
>>
>> Nit: "mutual-TLS"
>>
>> >  Mutual TLS certificate-bound access tokens ensure that only the party
>>
>> Nit: "Mutual-TLS"
>>
>> >  Mutual TLS certificate-bound access tokens and mutual TLS client
>>
>> Nit: "Mutual-TLS... mutual-TLS"
>>
>> >  Additional client metadata parameters are introduced by this document
>> >  in support of certificate-bound access tokens and mutual TLS client
>> >  authentication.
>>
>> Nit: "mutual-TLS"
>>
>> The remainder of the document has several other uses of the phrase "mutual
>> TLS" as an adjective; they should be similarly hyphenated. I will not call
>> them out individually. (Non-adjectival uses should not contain hyphens, so
>> this isn't a simple find-and-replace operation.)
>>
>
> Understood. In theory anyway.  I'll take a pass thought the whole document
> and endeavor to find and hyphenate all the places t

Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-mtls-16: (with DISCUSS and COMMENT)

[Brian Campbell]

I missed responding to this one part below about sec 7.2 and yet somehow
remembered that I'd missed it. Anyway, I feel like I had some seemingly
legitimate reason for mentioning (first) preimage when I wrote that text
but I cannot recall what that was and, on reading the text again with the
benefit of your comment, I think you are right. Second-preimage resistance
is what we care about in this context. I'll drop mention of regular
preimage.


> Section 7.2
>
> I'm not sure why we mention both (first) preimage and second-preimage
> resistance, as they're pretty different properties.  I suppose there
> could be some registration scenarios where only the thumbprint is
> provided and thus an attacker with a DB dump would not have the first
> preimage in the form of the actual intended certificate, but even if
> they could reconstruct that "real" preimage from the thumbprint they
> wouldn't have the corresponding private key.  So second-preimage
> probably covers what we need, and we can assume that the "first"
> preimage (certificate) is always available to the attacker.





On Wed, Aug 21, 2019 at 3:21 PM Brian Campbell 
wrote:

> Thanks Ben, I attempt (over the course of many hours) to respond to your
> comments and discuss your discuss inline below.
>
> On Mon, Aug 19, 2019 at 4:15 PM Benjamin Kaduk via Datatracker <
> nore...@ietf.org> wrote:
>
>> Benjamin Kaduk has entered the following ballot position for
>> draft-ietf-oauth-mtls-16: Discuss
>>
>> --
>> DISCUSS:
>> --
>>
>> (1) I think that we need some text that covers how the resource server
>> will know to use mtls (and thus, to send a CertificateRequest to the
>> client during the TLS handshake).  The authorization server and client
>> can indicate their capabilities/preference via the RFC 8414 and RFC 7591
>> discovery and registration procedures, but I didn't see any discussion
>> of how an AS might know a RS's capabilities, or how an RS might develop
>> expectations of the capabilities of the clients accessing it.  A naive
>> conclusion might be that any given RS (hostname+port) would have to
>> either always or never use mtls, given the misordering between TLS
>> handshake completion and delivery of TLS application data (i.e.,
>> including the oauth token), though there may be refinements available in
>> the form of the unpopular TLS 1.2 renegotiation or TLS 1.3
>> post-handshake authentication (or exported authenticators).  Doing
>> either of those in an environment with TLS Termination per Section 6.5
>> may entail additional complications.
>>
>
> Is there some text that you can propose?
>
> Whether or not to ask for or require MTLS and how to determine when is
> going to be a deployment decision of the RS. I don't think what you
> describe as the naive conclusion is all that naive at all. But maybe that
> just makes me naive:) In implementations/deployments that I've seen thus
> far, a particular RS decides (or is dictated by some policy) that its stuff
> is high value enough that it needs cert-bound access tokens so it always
> sends a CertificateRequest to the client during the TLS handshake. Such an
> RS that also wants to allow access via non cert-bound access tokens might
> just let the TLS connection proceed even if the client doesn't offer a
> certificate or it might offer its stuff on a different host and/or port
> that is just regular TLS. I don't want to preclude the use of renegotiation
> or post-handshake authentication but (other than some past pain with
> renegotiation) I'm not really qualified to discuss or make recommendations
> about using them.
>
> Note also there is not something like RFC 8414 and RFC 7591 for RSs and
> (for good reasons I think) the WG has balked at working on something like
> that. So the requirements/capabilities/preferences of an RS will need to be
> communicated or configured out-of-band. And that's the case in general for
> RSs independent of this document.
>
> (We may also want some additional text discussing error handling for the
>> client/AS interaction, e.g., if a request shows up from a client-id that
>> should be using mtls but did not provide a certificate in the TLS
>> handshake, but that is only debatably something that rises to
>> Discuss-level; or if a client that advertised an intent to use MTLS used
>> the regular token endpoint and not the mtls endpoint alias (if they
>> differ).)
>>
>
> The end of sec 2
> https://tools.ietf.org/html/draft-ietf-oaut

Re: [OAUTH-WG] Adam Roach's No Objection on draft-ietf-oauth-mtls-16: (with COMMENT)

[Brian Campbell]

Thanks Adam, I attempt to provide not-too-terrible replies to your comments
inline below.

On Mon, Aug 19, 2019 at 8:02 PM Adam Roach via Datatracker 
wrote:

> --
> COMMENT:
> --
>
>
> Thanks for the work that everyone did on this document. I have one
> suggestion
> for clarification, followed by a handful of editorial nits.
>
> ---
>
> §2.1.2:
>
> >  tls_client_auth_san_ip
> > A string representation of an IP address in either dotted decimal
> > notation (for IPv4) or colon-delimited hexadecimal (for IPv6, as
> > defined in [RFC4291] section 2.2) that is expected to be present
> > as an iPAddress SAN entry in the certificate, which the OAuth
> > client will use in mutual TLS authentication.
>
> This probably needs some text that clarifies expectations around comparison
> and/or normalization. For example, if the iPAddress value in the cert is
> "20 01 0d b8 00 00 00 00 00 00 00 00 c0 00 02 ca" (and a mask of all F's),
> one
> should presume that this would match both tls_client_auth_san_ip values
> "2001:db8:0:0:0:0:c000:2ca" and "2001:DB8::192.0.2.202", right? If no, then
> this document needs to talk about normalization of address representation..
>

Can you help me with some text here? I'm a bit out of my realm, to be
honest. I naively just want it to say that the tls_client_auth_san_ip value
and iPAddress value in the cert need to be the same IP address. But I do
realize "same" isn't totally clear as your comment and others have pointed
out. But I don't know enough to know how to write it in a way that's
suitable for this kind of thing.

Alternatively, as I mentioned in my response to Ben (down a ways in
https://mailarchive.ietf.org/arch/msg/oauth/TMaNYXJgZ3-kz4GNsIL4O-9ncgQ),
I've never personally been able to think of a situation where
tls_client_auth_san_ip is actually needed.  So maybe removing it all
together is an option as well?



> ---
>
> §1:
>
> >  Layering on the abstract flow above, this document standardizes
> >  enhanced security options for OAuth 2.0 utilizing client certificate
> >  based mutual TLS.
>
> Nit: "client-certificate-based"
>

Mr. Kaduk beat you to this one. Will fix.


>  OAuth 2.0 defines a shared secret method of client authentication but
>
> Nit: "shared-secret"
>

Will fix.


>
> ---
> §1:
>
> >  This document describes an additional
> >  mechanism of client authentication utilizing mutual TLS certificate-
> >  based authentication
>
> Nit: "mutual-TLS"
>
> >  Mutual TLS certificate-bound access tokens ensure that only the party
>
> Nit: "Mutual-TLS"
>
> >  Mutual TLS certificate-bound access tokens and mutual TLS client
>
> Nit: "Mutual-TLS... mutual-TLS"
>
> >  Additional client metadata parameters are introduced by this document
> >  in support of certificate-bound access tokens and mutual TLS client
> >  authentication.
>
> Nit: "mutual-TLS"
>
> The remainder of the document has several other uses of the phrase "mutual
> TLS" as an adjective; they should be similarly hyphenated. I will not call
> them out individually. (Non-adjectival uses should not contain hyphens, so
> this isn't a simple find-and-replace operation.)
>

Understood. In theory anyway.  I'll take a pass thought the whole document
and endeavor to find and hyphenate all the places that "mutual TLS" is used
as an adjective.



>
> ---
>
> §5:
>
> >  Authorization servers supporting both clients using mutual TLS and
> >  conventional clients MAY chose to isolate the server side mutual TLS
> >  behaviour to only clients intending to do mutual TLS, thus avoiding
>
> Nit: "behavior" (or adjust other spellings in the document to be
> consistently
> British).
>

 Ugh. I'm surprised my jingoistic spellcheck didn't flag that one. Will
fix.

-- 
_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] Suresh Krishnan's No Objection on draft-ietf-oauth-mtls-16: (with COMMENT)

[Brian Campbell]

Thanks Suresh, I'll consider using RFC5952 there as I try and work though
some other comments on that parameter in that section.

On Tue, Aug 20, 2019 at 1:16 PM Suresh Krishnan via Datatracker <
nore...@ietf.org> wrote:

>
> --
> COMMENT:
> --
>
> * Section 2.1.2.
>
> Suggest using the IPv6 Address Text Representation described in RFC5952
> instead
> of using the representations described in RFC4291 section 2.2. The
> canonical
> representation described in RFC5952 makes it easier to compare two IPv6
> address
> strings which is probably something you want to do while doing mutual
> authentication.
>
>
> ___
> 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] Benjamin Kaduk's Discuss on draft-ietf-oauth-mtls-16: (with DISCUSS and COMMENT)

[Brian Campbell]

Thanks Ben, I attempt (over the course of many hours) to respond to your
comments and discuss your discuss inline below.

On Mon, Aug 19, 2019 at 4:15 PM Benjamin Kaduk via Datatracker <
nore...@ietf.org> wrote:

> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-oauth-mtls-16: Discuss
>
> --
> DISCUSS:
> --
>
> (1) I think that we need some text that covers how the resource server
> will know to use mtls (and thus, to send a CertificateRequest to the
> client during the TLS handshake).  The authorization server and client
> can indicate their capabilities/preference via the RFC 8414 and RFC 7591
> discovery and registration procedures, but I didn't see any discussion
> of how an AS might know a RS's capabilities, or how an RS might develop
> expectations of the capabilities of the clients accessing it.  A naive
> conclusion might be that any given RS (hostname+port) would have to
> either always or never use mtls, given the misordering between TLS
> handshake completion and delivery of TLS application data (i.e.,
> including the oauth token), though there may be refinements available in
> the form of the unpopular TLS 1.2 renegotiation or TLS 1.3
> post-handshake authentication (or exported authenticators).  Doing
> either of those in an environment with TLS Termination per Section 6.5
> may entail additional complications.
>

Is there some text that you can propose?

Whether or not to ask for or require MTLS and how to determine when is
going to be a deployment decision of the RS. I don't think what you
describe as the naive conclusion is all that naive at all. But maybe that
just makes me naive:) In implementations/deployments that I've seen thus
far, a particular RS decides (or is dictated by some policy) that its stuff
is high value enough that it needs cert-bound access tokens so it always
sends a CertificateRequest to the client during the TLS handshake. Such an
RS that also wants to allow access via non cert-bound access tokens might
just let the TLS connection proceed even if the client doesn't offer a
certificate or it might offer its stuff on a different host and/or port
that is just regular TLS. I don't want to preclude the use of renegotiation
or post-handshake authentication but (other than some past pain with
renegotiation) I'm not really qualified to discuss or make recommendations
about using them.

Note also there is not something like RFC 8414 and RFC 7591 for RSs and
(for good reasons I think) the WG has balked at working on something like
that. So the requirements/capabilities/preferences of an RS will need to be
communicated or configured out-of-band. And that's the case in general for
RSs independent of this document.

(We may also want some additional text discussing error handling for the
> client/AS interaction, e.g., if a request shows up from a client-id that
> should be using mtls but did not provide a certificate in the TLS
> handshake, but that is only debatably something that rises to
> Discuss-level; or if a client that advertised an intent to use MTLS used
> the regular token endpoint and not the mtls endpoint alias (if they
> differ).)
>

The end of sec 2
https://tools.ietf.org/html/draft-ietf-oauth-mtls-16#section-2
 says what to do in the case of a certificate mismatch in client auth:
   "If the presented certificate doesn't match that
   which is expected for the given "client_id", the authorization server
   returns a normal OAuth 2.0 error response per Section 5.2 of RFC6749
   [RFC6749] with the "invalid_client" error code to indicate failed
   client authentication."

And my intent and assumption was that a mismatch covered the case where no
certificate was presented (i.e. null cert doesn't match expected cert just
as different cert doesn't match). But perhaps that particular case should
be made more explicit?  The second to last paragraph of sec 3
https://tools.ietf.org/html/draft-ietf-oauth-mtls-16#section-3 has similar
guidance for error handing in the case of mismatch during resource access.

The case of a so called public client that has
tls_client_certificate_bound_access_tokens metadata of true that shows up
at the token endpoint without having done MTLS is a bit more nuanced and I
think it's untimely a policy decision for the AS at that point as to
whether to error or issue an unbound token.



>
> (2) I can't validate the examples in Appendix A.
>
> Specifically, my reading of the text would put the "x5t#S256" value as
> needing 86 characters, but only 43 are provided.  The ones there also do
> not seem to be a prefix of the result that I get from taking the PEM
> certificate contents and running them through the pipeline:
>
> base64 -di | sha256sum |awk '{print $1}'|tr -d '\n'|base64
>
> (Noting, of course, that 'base64' will be producing the non-URL-safe
> variant, but expecting it to remain "pre

Re: [OAUTH-WG] New OAuth DPoP and Security BCP drafts

[Brian Campbell]

It can be a bit of a balancing act to have examples that clearly and
concisely demonstrate the target functionality of the document but do so in
the context of an otherwise complete and valid protocol message that also
shows best practices being adhered to. But I think in this case I agree
that adding a code_verifier to that example is worthwhile to show one of
the generally agreed on best practices being followed and it doesn't add
too much bloat to the example.


On Thu, Aug 1, 2019 at 2:44 PM Sascha Preibisch 
wrote:

> Hi all!
>
> I am reading through the latest draft ( ... dpop-02). When I got to
> the first example request (bullet 5.) I saw that only 'grant_type,
> code, redirect_uri' are used.
>
> If I am not mistaken the recommendation is to generally use PKCE with
> an authorization_code flow. Therefore, I wondered if the example
> should also include a 'code_verifier'.
>
> Thanks,
> Sascha
>
> On Mon, 8 Jul 2019 at 06:30, Daniel Fett  wrote:
> >
> > All,
> >
> > In preparation for the meeting in Montreal, I just uploaded a new
> version of the DPoP draft:
> > https://tools.ietf.org/html/draft-fett-oauth-dpop-02
> >
> > Please have a look and let me know what you think. We should make this a
> working group item soon.
> >
> > As you might have noticed, there is also a new version of the Security
> Best Current Practice draft:
> > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13
> >
> > -Daniel
> > ___
> > 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] Genart last call review of draft-ietf-oauth-resource-indicators-05

[Brian Campbell]

Thanks for the review Stewart and my apologies for the slow response - I
left on a longish summer family vacation the day before the review email
hit my inbox.

I've fixed the nit by using "JSON Web Token (JWT)" on that first use in the
source controlled editor's xml version and it'll show up in the next draft
revision.


On Tue, Jul 30, 2019 at 11:35 AM Stewart Bryant via Datatracker <
nore...@ietf.org> wrote:

> Reviewer: Stewart Bryant
> Review result: Ready
>
> 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-resource-indicators-05
> Reviewer: Stewart Bryant
> Review Date: 2019-07-30
> IETF LC End Date: 2019-08-05
> IESG Telechat date: Not scheduled for a telechat
>
> Summary: A well written document ready for publication.  It has one very
> minor
> nit that needs to be addressed at some point.
>
> Major issues: None
>
> Minor issues: None
>
> Nits/editorial comments:  JWT is not in the well known list and does not
> seem
> to be expanded on first use,
>
>
>

-- 
_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] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwsreq-19: (with DISCUSS and COMMENT)

[Brian Campbell]

To be accurate, I'm one of the DEs on the JWT Claims registry
https://www.iana.org/assignments/jwt/jwt.xhtml while Hannes is the DE on
the OAuth Parameters registry
https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#parameters
FWIW.

To completely lock it all down and absolutely avoid collisions in all cases
(all cases that bother to consult the registries anyway), I suppose the two
registries would need to be reconciled and then kept perfectly in sync
going forward. Or even merged into a single super registry. But, to me
anyway, that seems like a huge PITA that's overkill and doesn't account for
the context of use with respect to likelihood of actual collisions.

JAR is a  specific application of JWT that is being used to convey an OAuth
authz request. The collisions that need to be avoided are in that narrow
context. JAR explicitly uses a few core JWT claims (aud, iss) so those need
to be accounted for by registering them as OAuth authorization request
parameters (with some explanation as such).  And one could reasonably
imagine some of the other core claims which are about the token itself
being used as well (exp, iat, nbf, jti, cnf, etc). So those should probably
be accounted for as well.

But most/all of the other JWT claims that have been registered, the SIP
CSeq numeric header field parameter value for example, are highly unlikely
to ever be used in the context of an OAuth authorization request. So won't
be a collision issue in the narrow context of a JWT secured authorization
request.  I think it's unlikely enough to be an issue that I think it's
sufficient to only register the core meta JWT claim names into the OAuth
parameters registry for the authorization request usage location.

True, that's not 100% guaranteed to guard against all collisions. But I
think it's pragmatic trade off that guards against all likly real world
collisions.

And if we are really worried about avoiding it 100% guaranteed all the
time, then JAR should wrap the authorization request parameters in a JSON
object so they have their own effectively distinct namespace. But I realize
that's a major change at this stage. Which leads me back to looking for a
simple(ish) and pragmatic approach to avoiding actual likely collisions.






On Sun, Jul 28, 2019 at 4:18 PM n-sakimura  wrote:

> Brian,
>
> You are the expert on the particular IANA registries so I probably are
> missing something.
>
> I was thinking that registering JWT claims to OAuth registry is sufficient
> till seeing Ben’s comment, and I was tracking that it is being done by Mike
> as part of the errata process for OIDC Core. However, after reading Ben’s
> comment that mentioning the OAuth extensions, and I checked that quite a
> few claims are now being registered to JWT Claims Registry from outside the
> OAuth community, I started to feel that it may not be sufficient. But I
> must be missing something as you point out that is still sufficient.
>
> Could you please explain how the collision between the future OAuth
> extension and JWT claims can be avoided by registering main JWT claims to
> the OAuth Parameter registry?
> If that is the case, I am all for it as then we do not get back to IANA
> process.
>
> Best,
>
> Nat
>
> Nat Sakimura | 崎村夏彦
> Nomura Research Institute
>
>
> このメールには、本来の宛先の方のみに限定された機密情報が含まれている場合がございます。お心あたりのない場合は、送信者にご連絡のうえ、このメールを削除してくださいますようお願い申し上げます。
>
> PLEASE READ：This e-mail is confidential and intended for the named
> recipient only. If you are not an intended recipient, please notify the
> sender and delete this e-mail.
>
> --
> *差出人:* Brian Campbell 
> *送信日時:* Saturday, July 27, 2019 5:47:15 AM
> *宛先:* Nat Sakimura 
> *CC:* Benjamin Kaduk ; draft-ietf-oauth-jws...@ietf.org <
> draft-ietf-oauth-jws...@ietf.org>; oauth-cha...@ietf.org <
> oauth-cha...@ietf.org>; The IESG ; oauth 
> *件名:* Re: [OAUTH-WG] Benjamin Kaduk's Discuss on
> draft-ietf-oauth-jwsreq-19: (with DISCUSS and COMMENT)
>
> Nat, you suggest that the "simplest solution probably is to register the
> authorization request parameters to the JWT Claims registry." However, as
> I've attempted to articulate several times this week (
> https://mailarchive.ietf.org/arch/msg/oauth/0EenxmThjII52SAr9atpBStRtcs
> and
> muliple comments on https://bitbucket.org/openid/connect/issues/1019) and
> even back in 2017 (
> https://mailarchive.ietf.org/arch/msg/oauth/_E14Trqu962cReu3t6FquPEyigY),
> I
> believe the pragmatic solution to this is to register some of the main JWT
> claims into the OAuth parameters registry (not the other way around, as
> you're suggesting which wouldn't even have caught the one name collision
> we've actually had where a draft, more than one actually, want

Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwsreq-19: (with DISCUSS and COMMENT)

[Brian Campbell]

I'm honestly not sure I follow all that or how it would really work to
prevent name collisions. As a lipnus test, would the one real world
instance of the issue (name collision with 'aud') have been averted by this?

While my understanding is obliviously a requirement here, I do have more
familiarity with this stuff than the average person, so my lack of
understanding might serve as a good indicator about the likely simplicity
and efficacy of what's been suggested.


On Sat, Jul 27, 2019 at 12:02 AM Nat Sakimura  wrote:

> Brian,
>
> Perhaps I should have spelled out what I have stated as "grandfather the
> currently registered OAuth Authorization Request parameters into JWT Claims
> Registry and keep any incoming OAuth Authz param in sync with the JWT
> Claims Registry by creating a modified instruction for IANA processings.
>
> I felt that to find out what is being added to the JWT Claims registry as
> potentially OAuth Authz Request extension parameters that are coming in the
> future a bit arbitrary and not-so-simple while an instruction to add
> incoming OAuth Authz Request parameters to JWT Claims Registry is
> deterministic and therefore simple.
>
> On Fri, Jul 26, 2019 at 4:47 PM Brian Campbell 
> wrote:
>
>> Nat, you suggest that the "simplest solution probably is to register the
>> authorization request parameters to the JWT Claims registry." However, as
>> I've attempted to articulate several times this week (
>> https://mailarchive.ietf.org/arch/msg/oauth/0EenxmThjII52SAr9atpBStRtcs
>> and muliple comments on https://bitbucket.org/openid/connect/issues/1019)
>> and even back in 2017 (
>> https://mailarchive.ietf.org/arch/msg/oauth/_E14Trqu962cReu3t6FquPEyigY),
>> I believe the pragmatic solution to this is to register some of the main
>> JWT claims into the OAuth parameters registry (not the other way around, as
>> you're suggesting which wouldn't even have caught the one name collision
>> we've actually had where a draft, more than one actually, wanted to call an
>> authorization request parameter "aud", which would conflicted with the JWT
>> claim of the same name and cause big problems when used together with JAR).
>> I suppose the iron clad way to "fix" this would be to merge the two
>> registries and keep them in sync forever. But that seems awfully heavy
>> handed and unnecessary. JAR is a specific application of JWT being used to
>> convey an OAuth authz request. JAR explicitly uses a few core JWT claims
>> (aud, iss) and one could reasonably imagine other core ones being used as
>> well (exp, iat, nbf, jti, etc). An authorization request parameter being
>> introduced that uses one of those names is far and away the most likely
>> point of collision (and has already happened, as noted previously). A new
>> JWT claim being introduced that collides with an existing authorization
>> request parameter name AND would be used in the context of JAR is far far
>> less likely to happen. So unlikely, in fact, that I don't think it's
>> necessary or even useful to pollute the JWT claims registry with the names
>> of all the authorization request parameters. I happen to be one of the DEs
>> on the JWT claims registry so, in theory, I have some idea what I'm talking
>> about here. In theory. And I do have to be upfront at this point and say
>> that I will push back on a request for registration of a bunch of
>> authorization request parameters into the JWT claims registry without
>> without more compelling reason.
>>
>> On Fri, Jul 26, 2019 at 12:23 PM Nat Sakimura  wrote:
>>
>>>
>>> Thanks very much for the comments.
>>> Here are my responses to your comments.
>>>
>>> On Wed, Jul 3, 2019 at 2:59 PM Benjamin Kaduk via Datatracker <
>>> nore...@ietf.org> wrote:
>>> >
>>> > Benjamin Kaduk has entered the following ballot position for
>>> > draft-ietf-oauth-jwsreq-19: Discuss
>>> >
>>> > When responding, please keep the subject line intact and reply to all
>>> > email addresses included in the To and CC lines. (Feel free to cut this
>>> > introductory paragraph, however.)
>>> >
>>> >
>>> > Please refer to
>>> https://www.ietf.org/iesg/statement/discuss-criteria.html
>>> > for more information about IESG DISCUSS and COMMENT positions.
>>> >
>>> >
>>> > The document, along with other ballot positions, can be found here:
>>> > https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/
>>> >
>>> >
>

Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwsreq-19: (with DISCUSS and COMMENT)

[Brian Campbell]

Nat, you suggest that the "simplest solution probably is to register the
authorization request parameters to the JWT Claims registry." However, as
I've attempted to articulate several times this week (
https://mailarchive.ietf.org/arch/msg/oauth/0EenxmThjII52SAr9atpBStRtcs and
muliple comments on https://bitbucket.org/openid/connect/issues/1019) and
even back in 2017 (
https://mailarchive.ietf.org/arch/msg/oauth/_E14Trqu962cReu3t6FquPEyigY), I
believe the pragmatic solution to this is to register some of the main JWT
claims into the OAuth parameters registry (not the other way around, as
you're suggesting which wouldn't even have caught the one name collision
we've actually had where a draft, more than one actually, wanted to call an
authorization request parameter "aud", which would conflicted with the JWT
claim of the same name and cause big problems when used together with JAR).
I suppose the iron clad way to "fix" this would be to merge the two
registries and keep them in sync forever. But that seems awfully heavy
handed and unnecessary. JAR is a specific application of JWT being used to
convey an OAuth authz request. JAR explicitly uses a few core JWT claims
(aud, iss) and one could reasonably imagine other core ones being used as
well (exp, iat, nbf, jti, etc). An authorization request parameter being
introduced that uses one of those names is far and away the most likely
point of collision (and has already happened, as noted previously). A new
JWT claim being introduced that collides with an existing authorization
request parameter name AND would be used in the context of JAR is far far
less likely to happen. So unlikely, in fact, that I don't think it's
necessary or even useful to pollute the JWT claims registry with the names
of all the authorization request parameters. I happen to be one of the DEs
on the JWT claims registry so, in theory, I have some idea what I'm talking
about here. In theory. And I do have to be upfront at this point and say
that I will push back on a request for registration of a bunch of
authorization request parameters into the JWT claims registry without
without more compelling reason.

On Fri, Jul 26, 2019 at 12:23 PM Nat Sakimura  wrote:

>
> Thanks very much for the comments.
> Here are my responses to your comments.
>
> On Wed, Jul 3, 2019 at 2:59 PM Benjamin Kaduk via Datatracker <
> nore...@ietf.org> wrote:
> >
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-oauth-jwsreq-19: Discuss
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> >
> >
> > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/
> >
> >
> >
> > --
> > DISCUSS:
> > --
> >
> > My apologies; my previous position was incomplete.  Updated to note
> > namespacing issues, and one minor terminology nit about "DNS-ID".
> >
> > There seem to be some pretty serious namespacing issues that are not
> > discussed at all in this document.  Specifically, using JWT as a
> > container for OAuth 2.0 authorization request parameters (including
> > extension parameters) introduces the usage of many new names (of JSON
> > name/value pairs) into the JWT claims namespace.  Furthermore, the
> > addition is not bounded, as any new OAuth extension parameters are
> > implicitly permitted to be used as well!  The IANA Considerations make
> > no mention of the collapsed namespace for JWT claims and OAuth 2.0
> > (authorization request) parameters, leaving substantial potential for
> > collisions in the future.
>
> The simplest solution probably is to register the authorization request
> parameters to the JWT Claims registry.
> According to my checking, the relevant but not yet registered parameters
> are:
>
> Claim Name: "code_challenge"
> Claim Description: OAuth PKCE Code Challenge
> Change Controller: IESG
> Specification Document(s): Section 3 of RFC 7636
>
> Claim Name: "code_challenge_method"
> Claim Description: OAuth PKCE Code Challenge
> Change Controller: IESG
> Specification Document(s): Section 3 of RFC 7636
>
> Claim Name: "redirect_uri"
> Claim Description: OAuth Redirection URI
> Change Controller: IETF
> Specification Document(s): Section 4.1.1 of RFC 6749
>
> Claim Name: "response_type"
> Claim Description: OAuth Authorization Response type
> Change Controller: IETF
> Specification Document(s): Section 3.1.1 of RFC 6749
>
> Claim Name: "state"
> Claim Description: OAuth state parameter
> Change Controller: IETF
> Specification Document(s): Section 4.1.1 of RFC 6749
>
> Claim Name: 

Re: [OAUTH-WG] Secdir last call review of draft-ietf-oauth-mtls-15

[Brian Campbell]

Thanks Vincent, I've fixed the nit in the source controlled editor's xml
version and it'll show up in the next draft revision.

On Thu, Jul 25, 2019 at 3:06 PM Vincent Roca via Datatracker <
nore...@ietf.org> wrote:

> Reviewer: Vincent Roca
> Review result: Ready
>
> Hello,
>
> I have reviewed this document as part of the security directorate’s ongoing
> effort to review all IETF documents being processed by the IESG. These
> comments were written primarily for the benefit of the security area
> directors.  Document editors and WG chairs should treat these comments just
> like any other last call comments.
>
> Summary: Ready
>
> The Security considerations and privacy considerations sections both look
> sound
> to me.
>
> Nits:
> * section 7.1: s/to which they where issued/to which they were issued/
>
> Cheers.  Vincent
>
>
>
>

-- 
_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] Guidance for which key to use for JWE encryption? (draft-ietf-oauth-jwsreq-19)

[Brian Campbell]

I'd say this one->* any "enc" key published by the AS on its jwks_uri?

On Thu, Jul 25, 2019 at 3:50 PM Танги Ле Пенс  wrote:

> Dear all,
>
> draft-ietf-oauth-jwsreq-19 gives guidance on which key use to verify a
> JWS' signature (the client's key)
> (https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-6.2).
>
> However there no such guidance for JWE encryption:
>
> * any "enc" key published by the AS on its jwks_uri?
>
> * one specific key of the ones listed at the server's jwks_uri? If so,
> how to indicate which one in particular?
>
> * out-of-band configuration?
>
> And should it be part of the specification?
>
> Regards,
>
> --
>
> Tangui
>
> ___
> 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] a token review of draft-ietf-oauth-access-token-jwt-01/-02

[Brian Campbell]

You're welcome, of course. And thanks for the prompt response. I've
endeavored to continue the parts of the conversation that needed continuing
below.

On Wed, Jul 24, 2019 at 3:46 PM Vittorio Bertocci  wrote:

> Thank you Brian for the thorough and insightful review!
>
Comments:
>
> > On authenticated encryption.
> I did chat with Neil about his draft, but as you mention I didn't
> reference it given that it hasn't bee picked up (yet?).
> On referencing JWE RFC7516 and more JWA RFC7518, I am reluctant. My
> rationale is that this profile attempts to capture current practices or
> practices that are close enough to the capabilities of existing systems to
> have a reasonable chance of being adopted. None of the products/services
> surveyed used authenticated encryption, and the requirement to acquire a
> symmetric key out of band throws  a big wrench in the otherwise clear-cut
> process of preparing your RS to handle JWT ATs. I will bring the matter up
> as open issue on Friday, and if the consensus will be to include symmetric
> authenticated encryption I'll do that; but my personal preference would be
> to preserve the simplicity of a concrete,
> nothing-of-substance-left-as-exercise-to-the-reader solution that can be
> achieved when the key material can be advertised via metadata.
>

Looking to get consensus is quite reasonable, of course, and I can
sympathize with the aim of simplicity. As I've said before though, I think
the utility it brings is sufficient trade-off with respect to any
additional complexity it brings (which is arguably not that much). And I
imagine I'll continue to recommend it in situations where it makes sense
regardless of where this document ends up. But, well, you know, that's
just, like, my opinion, man.

To set the historical record straight, however, I was among the
products/services surveyed and I explicitly included several examples
showing "AEAD symmetric encrypted AT".



>
> About the nonce mitigation you mention. Do you think this means that I
> should explicitly forbid the presence of a "nonce" claim in JWT ATs?
>

I dunno to be honest. The actual validation of the nonce requires enough
other contortions that it probably doesn't really need to be forbidden
here. And proper use of aud (and maybe other stuff?) stuff also makes using
a AT as an ID token infeasible. So it's okay as is as far as I can tell.
But maybe forbidding nonce isn't a bad suggestion just for the sake of
saying something about it and maybe avoiding some potential mix-ups.



>
> >I think you want to say here that the scope claim in the token has to
> correlate to the scope which was approved. Not necessarily what what
> requested. The authorization request might ask for scope of a+b+c, for
> example, while the user only approves b. Or any other variation on things
> where what was asked for isn't what was gotten..
>
> Here I am trying not to get into the details of what's inside the scope
> claim, more requesting that if "scope" was in the request, the issued token
> should express a delegation and a symptom of that should be the presence of
> the scope claim. Paradoxically that scope claim might be empty if the user
> only consented to scopes that have effect on the presence of other claims
> in the token (say a functional equivalent of profile). Yes, it does sound
> odd, but that's a side effect of the prohibition of sending id_tokens to
> API that creates the requirement to create functional equivalents.
>

I must admit to not 100% following all of that I want to bring it back up
to the text in the draft, which to me, reads as saying that if the authz
request contains a scope, then the AT SHOULD contain a scope (noting that
SHOULD is still actually pretty strong language per RFC2119). I think
that's too strong a correlation between something maybe in the authz
request and a claim in the AT.

I *think* it'd be preferable to say something similar to the effect of (and
it sounds almost silly but it's not meant to), "the scope claim has the
scope". Maybe something along these lines in place of the first
sentence/paragraph of 2.2.2.

  "The issued JWT access token SHOULD/MAY/can/could/will/might include a
scope claim as
   defined in section 4.2 of [TE], which expresses the scope of access
authorized by the token."


>I personally think the SHOULD is too strong here because it puts the onus
> on the resource server to know about (via some config option or something)
> and enforce on every transaction a setup/policy thing that the AS is
> responsible for which isn't about the integrity of the authorization data
> in the token. A MAY or even removing the list item would be preferred.
>
> I borrowed this language straight from the OpenID Connect validation steps
> for idtokens. Given that JWT ATs can carry identity info, the requirement
> seemed appropriate... also, I think it is reasonable to expect the resource
> server to know about its own registration- just like it must know about the
> expected aud val

[OAUTH-WG] a token review of draft-ietf-oauth-access-token-jwt-01/-02

[Brian Campbell]

ope confusion include
>"scope stuffing", imposing to every individual scope string to
>include a reference to the resource they are meant to be applied to,
>but its application is problematic (scope opacity violations, size
>inflation, more error conditions become possible when the combination
>of requested scopes and resource indicators is invalid) and the
>observed frequency of the scenario doesn't warrant complicating the
>more common cases.
>
I do think I see the simplification you're aiming at with this stuff but
I'd like to offer the perspective of how this is likely more complicated
for standards based JWT library implementations. The semantics of aud in
RFC 7519 basically say that the recipient has to identify with at least one
of the aud values. It's effectively a big OR. While the text in this draft
changes that semantic to say that the recipient has to identify with at
every one of the aud values. Effectively making it a big AND. Normal JWT
libraries will need nonstandard one-off functionality or adaptations to get
this right.


 4.  Validating JWT Access Tokens

>   The resource server MUST validate the signature of all incoming
>JWT access token according to [RFC7515] using the algorithm
>specified in the JWT alg Header Parameter.  The resource server
>MUST use the keys provided by the authorization server.
>
I think it'd be worthwhile to explicitly disallow the use of the "none"
algorithm here. I think/suspect that it is implied already. But at least
some of the JWT hate out there seems to stem from or focus on statements
like this one and conclude that words like "MUST validate ... according to
[the] algorithm specified in the JWT alg Header Parameter" means that to be
spec compliant one has to accept "alg":"none" as valid. That's more of a
logical leap than I think is reasonable but I'd like to avoid it anyway if
possible. And it's not a bad thing to remind folks not to accept "none"
here.

7.2.  Claims Registration

> claims in the JSON Web TOken (JWT) IANA
>
Little 'o' in TOken -> Token


7.2.1.  Registry Contents
|   Specification Document(s): section 4.1.2 of [RFC7643]
Ultimately this is what will show up in the "References" column in the
registry https://www.iana.org/assignments/jwt/jwt.xhtml and thus I'd
suggest that it also include something like "Section 2.2.2.1 of [[this
specification]]" there too so someone who starts from the registry has the
link to and context of this document. A link directly to SCIM alone from
the JSON Web Token Claims registry might be rather confusing.
For the folks that will have to review and act on these registrations at
some point, it might be nice to give em a little better
grouping/formatting. I'm thinking along the lines of what is done here
https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-18#section-7.4.1,
which you can corice xml2rfc into doing with  and  as in the src at
https://github.com/oauth-token-exchange/spec/blob/master/draft-ietf-oauth-token-exchange.xml#L1191

Appendix A.  Acknowledgements

> Brian Campbell (PingIdentity)
>
My corporate overloads will be happier if you put a space between Ping and
Identity.

-- 
_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-WG] oauth-jwsreq & parameter registration

[Brian Campbell]

In the WG meeting yesterday I mentioned that I thought there might have had
been some action already taken with respect to "JWT Secured Authorization
Request (JAR)" and the potential name conflicts between authorization
parameters and JWT claims.

I tracked down this ticket in the OpenID Connect WG
https://bitbucket.org/openid/connect/issues/1019/core-iana-consideration,
which touches on the issue but it doesn't look like any action has actually
been taken.

I do think that what is mentioned in the ticket (effectively registering
some core "meta" JWT claims as authorization request parameters) is
pragmatic and sufficient.

As one data point, as far as I know, "aud" is the only name where we've
actually encountered this particular name collision problem.

-- 
_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] New OAuth for Browser-Based Apps draft -02

[Brian Campbell]

On Mon, Jul 22, 2019 at 7:31 AM Torsten Lodderstedt 
wrote:

>
> 2) Regarding architectures: I think this BCP should focus on
> recommendations for securely implementing OAuth in the different potential
> architecture. I don’t think we should get into the business of recommending
> and assessing other solutions (e.g. section 6.1.). Just to give you an
> example: Section 6.1. states
>
> "OAuth and OpenID Connect provide very little benefit in this deployment
> scenario, so it is recommended to reconsider whether you need OAuth or
> OpenID Connect at all in this case.”
>
> Really? What experiences is this statement based on? In my experience,
> sharing the same domain == host name tells you nothing about the overall
> architecture of a certain deployment. There may be several reasons why
> OAuth could be good choice in such a scenario, e.g. security considerations
> (since your common domain is just a proxy server encapsulating a whole
> universe of systems) or even modularity as an architecture principle.
>
> I suggest to remove section c. and to rephrase the second paragraph of the
> abstract.
>

I believe the experiences that the statement is based on are the
predominant practice over the course of much of the history of the web of
using a cookie to maintain an authenticated HTTP session in web
applications. When the script of the browser-based application is served
from a domain that can share cookies with the domain of the API, then
cookies can still be used to authorize requests (even if those requests are
API calls rather than full page HTTP request/response). And I do believe
that's likely a better decision in a lot of such cases.

That authenticated HTTP session may be establish from a username/password
form submission, FIDO/WebAuthn, or whatever.  Even as a result of an OpenID
Connect flow. Or even SAML for that matter. But the the requests after that
are authorized by the cookie.

I think there's a tendency to assume because SPA style apps make API calls,
they simply must use OAuth. Because API implies OAuth in the minds of many
(which is a sign of its success). But OAuth isn't necessarily the only
thing that can be used for API authorization. Cookies work too. I
think/hope that's what Section 6.1. is getting at - providing some
potential guidance that OAuth might not necessarily be the right choice in
those cases where a common domain allows for a cookie. Perhaps the text in
that section could be phased in a different or better way, but I think its
useful to have some mention of in this document.

Although taking out "and OpenID Connect" from the sentence quoted above
might be more appropriate and alleviate some confusion.

-- 
_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] little nit on draft-ietf-oauth-security-topics-13 wrt ietf-oauth-mtls

[Brian Campbell]

One more thing I just noticed is that RFC8418 is used as a reference in a
few places that I suspect should be RFC8414.

https://tools.ietf.org/html/rfc8418 : Use of the Elliptic Curve
Diffie-Hellman Key Agreement Algorithm with X25519 and X448 in the
Cryptographic Message Syntax (CMS)

https://tools.ietf.org/html/rfc8414 : OAuth 2.0 Authorization Server
Metadata


On Tue, Jul 23, 2019 at 5:19 AM Daniel Fett  wrote:

> Thanks Brian, I committed a fix for this.
>
> -Daniel
>
> Am 22.07.19 um 20:36 schrieb Brian Campbell:
>
> The description of I-D.ietf-oauth-mtls in
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-4..8.1.2
> <https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-4.8..1.2>
> talks about binding to and checking against the fingerprint of the public
> key from the client certificate. However,
> https://tools.ietf.org/html/draft-ietf-oauth-mtls-15 uses a hash of the
> whole certificate rather than of just the public key.
>
> *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 listOAuth@ietf.orghttps://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

[OAUTH-WG] little nit on draft-ietf-oauth-security-topics-13 wrt ietf-oauth-mtls

[Brian Campbell]

The description of I-D.ietf-oauth-mtls in
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-4.8..1.2
talks about binding to and checking against the fingerprint of the public
key from the client certificate. However,
https://tools.ietf.org/html/draft-ietf-oauth-mtls-15 uses a hash of the
whole certificate rather than of just the public key.

-- 
_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] AD Review: draft-ietf-oauth-resource-indicators-02

[Brian Campbell]

Hi Roman,

Thanks again for sticking with me through this one with and associated
registry updates with token exchange as well as my temporarily overlooking
some needed changes.

-04 is now up
<https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-04> and
this time I think I've actually addressed all your comments.



On Mon, Jul 22, 2019 at 7:11 AM Roman Danyliw  wrote:

> Hi Brian!
>
>
>
> *From:* Brian Campbell [mailto:bcampb...@pingidentity.com]
> *Sent:* Monday, July 22, 2019 8:37 AM
> *To:* Roman Danyliw 
> *Cc:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] AD Review:
> draft-ietf-oauth-resource-indicators-02
>
>
>
> Yes, sorry about that. I realized this yesterday and as tried to write
> quickly from from my phone just before my flight took off for Montreal
> <https://mailarchive.ietf.org/arch/msg/oauth/2ss3hDa0xPQxaWiW6txj9W-vpqo>,
> I'd gotten distracted with the question of what to do with the
> registrations and lost track of this fork of the thread.  There are indeed
> a couple of outstanding bits that need to be addressed in a -04.
>
>
>
> I'll change adapt to downscope.
>
>
> Regarding your unanswered questions from below - partially quoted here for
> reference:
>
>
>
> 'If the initial request was notionally a scope of “all the houses on the
> block”, but the server knew that this request was too broad and down-scoped
> to “only the corner house”, wouldn’t this actually be worse for privacy?'
> -> the idea there is privacy in terms of limiting what one service
> potentially leans about other services the user is using. In the houses on
> the block case you mentioned, the downscoping prevents the corner house
> from learning that the user also accesses the other houses on the block.
>
> 'I also don’t follow how reducing the scope impacts confidential data.' ->
> to be honest, this particular text came as a suggestion from another WG
> member on review of an earlier version of the document. So I struggle a bit
> to defend/explain it but I think the idea is that in some cases a scope
> value itself might contain sensitive data like an account number or
> transaction identifier (e.g. something like "acct:123456789" or
> "tx:987654321"). This is somewhat uncommon in practice today but does
> happen in some situations. The same principal of limiting the scopes
> revealed across different services applies here too but with arguably worse
> consequences due to the sensitive data within the scope value. It's the
> same concept though and I think the mention of confidential data and scope
> here in the document is more likely cause confusion than it is to help
> anything. As such, I'm proposing to change that sentence as follows to
> remove the confidential bit and somewhat better describe the cross-service
> scope revealing issue.
>
>
>
>   "This further improves privacy as scope values give an indication of
> what services the resource
>   owner uses and downscoping a token to only that which is needed for
> a particular service can
>
>   limit the extent to which such information is revealed across
> different services."
>
>
>
> [Roman]  Thanks for the explanation relative to my analogy.  I agree that
> the proposed text above is a lot clearer and it addresses my concern.
>
>
>
> Roman
>
>
>
>
>
> On Sun, Jul 21, 2019 at 4:53 PM Roman Danyliw  wrote:
>
> Hi Brian!
>
>
>
> Thanks for the update in -03.  The item below is the only thing that
> remains outstanding.
>
>
>
> Thanks,
>
> Roman
>
>
>
>
>
> *From:* Roman Danyliw
> *Sent:* Wednesday, July 17, 2019 6:05 PM
> *To:* Brian Campbell 
> *Cc:* oauth@ietf.org
> *Subject:* RE: [OAUTH-WG] AD Review:
> draft-ietf-oauth-resource-indicators-02
>
>
>
>
>
> *From:* Brian Campbell [mailto:bcampb...@pingidentity.com
> ]
> *Sent:* Wednesday, July 17, 2019 4:35 PM
> *To:* Roman Danyliw 
> *Cc:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] AD Review:
> draft-ietf-oauth-resource-indicators-02
>
>
>
> [snip]
>
>
>
> (2) Section 2.2.  in the sentence "To the extent possible, when issuing
> access tokens, the authorization server should adapt the scope value
> associated with an access token to the value the respective resource is
> able to process and needs to know":
>
> --  is this language suggesting that the authorization server is modifying
> the scope value based on the resource it sees?  I'm trying to understand
> what "adapt" means, especially in relation to the improved security and
> privacy the subsequent sentence suggests.
>
>

Re: [OAUTH-WG] AD Review: draft-ietf-oauth-resource-indicators-02

[Brian Campbell]

Yes, sorry about that. I realized this yesterday and as tried to write
quickly from from my phone just before my flight took off for Montreal
<https://mailarchive.ietf.org/arch/msg/oauth/2ss3hDa0xPQxaWiW6txj9W-vpqo>,
I'd gotten distracted with the question of what to do with the
registrations and lost track of this fork of the thread.  There are indeed
a couple of outstanding bits that need to be addressed in a -04.

I'll change adapt to downscope.

Regarding your unanswered questions from below - partially quoted here for
reference:

'If the initial request was notionally a scope of “all the houses on the
block”, but the server knew that this request was too broad and down-scoped
to “only the corner house”, wouldn’t this actually be worse for privacy?'
-> the idea there is privacy in terms of limiting what one service
potentially leans about other services the user is using. In the houses on
the block case you mentioned, the downscoping prevents the corner house
from learning that the user also accesses the other houses on the block.

'I also don’t follow how reducing the scope impacts confidential data.' ->
to be honest, this particular text came as a suggestion from another WG
member on review of an earlier version of the document. So I struggle a bit
to defend/explain it but I think the idea is that in some cases a scope
value itself might contain sensitive data like an account number or
transaction identifier (e.g. something like "acct:123456789" or
"tx:987654321"). This is somewhat uncommon in practice today but does
happen in some situations. The same principal of limiting the scopes
revealed across different services applies here too but with arguably worse
consequences due to the sensitive data within the scope value. It's the
same concept though and I think the mention of confidential data and scope
here in the document is more likely cause confusion than it is to help
anything. As such, I'm proposing to change that sentence as follows to
remove the confidential bit and somewhat better describe the cross-service
scope revealing issue.

  "This further improves privacy as scope values give an indication of
what services the resource
  owner uses and downscoping a token to only that which is needed for a
particular service can
  limit the extent to which such information is revealed across
different services."


On Sun, Jul 21, 2019 at 4:53 PM Roman Danyliw  wrote:

> Hi Brian!
>
>
>
> Thanks for the update in -03.  The item below is the only thing that
> remains outstanding.
>
>
>
> Thanks,
>
> Roman
>
>
>
>
>
> *From:* Roman Danyliw
> *Sent:* Wednesday, July 17, 2019 6:05 PM
> *To:* Brian Campbell 
> *Cc:* oauth@ietf.org
> *Subject:* RE: [OAUTH-WG] AD Review:
> draft-ietf-oauth-resource-indicators-02
>
>
>
>
>
> *From:* Brian Campbell [mailto:bcampb...@pingidentity.com
> ]
> *Sent:* Wednesday, July 17, 2019 4:35 PM
> *To:* Roman Danyliw 
> *Cc:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] AD Review:
> draft-ietf-oauth-resource-indicators-02
>
>
>
> [snip]
>
>
>
> (2) Section 2.2.  in the sentence "To the extent possible, when issuing
> access tokens, the authorization server should adapt the scope value
> associated with an access token to the value the respective resource is
> able to process and needs to know":
>
> --  is this language suggesting that the authorization server is modifying
> the scope value based on the resource it sees?  I'm trying to understand
> what "adapt" means, especially in relation to the improved security and
> privacy the subsequent sentence suggests.
>
>
>
> Perhaps "adapt" wasn't the best choice of word but it's meant to say that
> an authorization server with sufficient understanding of what scopes are
> applicable to what resources (which won't always be the case or even
> possible but sometimes) could limit the scope associated with an access
> token (downscoping really) to only the scope that is applicable to the
> resource.
>
>
>
> Some of the examples (figures 2 - 6) attempt to show, among other things,
> a hypothetical case of how this might go down.
>
>
>
> In Figure 2 the initial authorization request that's approved has scope of
> calendar & contacts and resources https://contacts.example.com/ &
> https://cal.example.com/
>
>
>
> A subsequent access token request (Figure 3) has resource
> https://cal.example.com/ and the issued access token scope (Figure 4) is
> "adapted" to that resource to be only calendar
>
>
>
> Another subsequent access token request (Figure 5) has resource
> https://contacts.example.com/ and the issued access token scope (F

Re: [OAUTH-WG] AD Review: draft-ietf-oauth-resource-indicators-02

[Brian Campbell]

Doh, I got distracted with the registration question and lost track of this
fork of the thread. I'll need to do a -04 also (after maybe some more
discussion too) before I pass the ball back to the AD.

On Wed, Jul 17, 2019, 4:04 PM Roman Danyliw  wrote:

> Hi Brian!
>
>
>
> *From:* Brian Campbell [mailto:bcampb...@pingidentity.com]
> *Sent:* Wednesday, July 17, 2019 4:35 PM
> *To:* Roman Danyliw 
> *Cc:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] AD Review:
> draft-ietf-oauth-resource-indicators-02
>
>
>
> Thank you, Roman, for the review. Some replies are inline below. I'll aim
> to push out a -03 addressing this stuff sometime not too long after the I-D
> submission embargo is lifted next week.
>
>
>
>
>
> On Tue, Jul 16, 2019 at 5:23 PM Roman Danyliw  wrote:
>
> Hi!
>
> The following is my AD review of draft-ietf-oauth-resource-indicators-02.
> The document is in good shape.
>
>
>
> That's always nice to hear :-)
>
>
>
>
> (1) Section 2. Per "The parameter can carry the location of a protected
> resource, typically as an https URL, or a more abstract identifier", is
> this "abstract identifier" still an absolute URI per Section 4.3 of RFC3986?
>
>
>
> Absolutely (see what I did there? sigh...). Syntactically it's an absolute
> URI. Semantically, while it might be an actual network addressable location
> identified by an HTTPS URL, it might also be a URN or something that more
> abstractly indicates a resource or grouping of resources. But its format is
> an absolute URI regardless.
>
>
>
> I'm not sure what, if anything, can be added or changed here to help
> clarify. But I'm happy to entertain suggestions, if you've got em and/or
> think something is needed.
>
>
>
> [Roman] Understood.  Concur there is nothing to do here.
>
>
>
>
> (2) Section 2.2.  in the sentence "To the extent possible, when issuing
> access tokens, the authorization server should adapt the scope value
> associated with an access token to the value the respective resource is
> able to process and needs to know":
>
> --  is this language suggesting that the authorization server is modifying
> the scope value based on the resource it sees?  I'm trying to understand
> what "adapt" means, especially in relation to the improved security and
> privacy the subsequent sentence suggests.
>
>
>
> Perhaps "adapt" wasn't the best choice of word but it's meant to say that
> an authorization server with sufficient understanding of what scopes are
> applicable to what resources (which won't always be the case or even
> possible but sometimes) could limit the scope associated with an access
> token (downscoping really) to only the scope that is applicable to the
> resource.
>
>
>
> Some of the examples (figures 2 - 6) attempt to show, among other things,
> a hypothetical case of how this might go down.
>
>
>
> In Figure 2 the initial authorization request that's approved has scope of
> calendar & contacts and resources https://contacts.example.com/ &
> https://cal.example.com/
>
>
>
> A subsequent access token request (Figure 3) has resource
> https://cal.example.com/ and the issued access token scope (Figure 4) is
> "adapted" to that resource to be only calendar
>
>
>
> Another subsequent access token request (Figure 5) has resource
> https://contacts.example.com/ and the issued access token scope (Figure
> 6) is downscoped based on that resource to be only contacts
>
>
>
> Would it be easier to understand if the word "downscope" was used rather
> than "adapt"?
>
>
>
> [Roman] Using “downscope” does work for me.  It captures that the server
> is going to reduce the scope (and certainly not expand it).
>
>
>
>
> -- (Depending on the above) Is there a security consideration here for the
> server relative to confidential scope values and how they might be modified?
>
>
>
> I'm not sure, to be honest. Downscopping when possible and to the extent
> possible is usually a good idea (least privilege and all that) but I think
> maybe I'm missing your point/question.
>
>
>
> [Roman] Yes, least privilege was part of it and I think the text above
> gets at it.  However, the other part is the relationship with the next
> sentence in the paragraph, “This further improves privacy as scope values
> give an indication of what services the resource owner uses and it improves
> security as scope values may contain confidential data”.  If the initial
> request was notionally a scope of “all the houses on the block”, b

Re: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-token-exchange-18: (with COMMENT)

[Brian Campbell]

https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-19 has been
published with the updates discussed in this thread.

On Sun, Jul 21, 2019 at 6:14 AM Brian Campbell 
wrote:

> That works for me.
>
> On Sat, Jul 20, 2019 at 10:28 PM Benjamin Kaduk  wrote:
>
>> On Fri, Jul 19, 2019 at 10:05:57AM -0600, Brian Campbell wrote:
>> > On Fri, Jul 19, 2019 at 8:31 AM Barry Leiba 
>> wrote:
>> >
>> > >
>> > > >> — Section 1.1 —
>> > > >> Given the extensive discussion of impersonation here, what strikes
>> me as
>> > > >> missing is pointing out that impersonation here is still
>> controlled,
>> > > that “A is
>> > > >> B” but only to the extent that’s allowed by the token.  First, it
>> might
>> > > be
>> > > >> limited by number of instances (one transaction only), by time of
>> day
>> > > (only for
>> > > >> 10 minutes), and by scope (in regard to B’s address book, but not
>> B’s
>> > > email).
>> > > >> Second, there is accountability: audit information still shows
>> that the
>> > > token
>> > > >> authorized acting as B.  Is that not worth clarifying?
>> > > >
>> > > > My initial response was going to be "sure, I'll add some bits in
>> sec 1.1
>> > > along those lines to clarify
>> > > > that." However, as I look again at that section for good
>> opportunities
>> > > to make such additions, I feel
>> > > > like it is already said that impersonation is controlled.
>> > > ...
>> > > > So I think it already says that and I'm gonna have to flip it back
>> and
>> > > ask if you have concrete
>> > > > suggestions for changes or additions that would say it more clearly
>> or
>> > > more to your liking?
>> > >
>> > > It is mentioned, true, and that might be enough.  But given that Eve
>> > > also replied that she would like more here, let me suggest something,
>> > > the use of which is entirely optional -- take it, don't take it,
>> > > modify it, riff on it, ignore it completely, as you think best.  What
>> > > do you think about changing the last sentence of the paragraph?: "For
>> > > all intents and purposes, when A is impersonating B, A is B within the
>> > > rights context authorized by the token, which could be limited in
>> > > scope or time, or by a one-time-use restriction."
>> > >
>> >
>> > Sure, I think that or some slight modification thereof can work just
>> fine.
>> > I'll do that and get it and the rest of these changes published when the
>> > I-D submission embargo is lifted for Montreal.
>>
>> My brain is apparntly storming and not sleeping.  Another option for
>> consideration, is to have two sentences:
>>
>> For all intents and purposes, when A is impersonating B, A is B within the
>> rights context authorized by the token.  A's ability to impersonate B
>> could
>> be limited in scope or time, or even with a one-time-use restriction,
>> whether via the contents of the token or an out-of-band mechanism.
>>
>> -Ben
>>
>

-- 
_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] Barry Leiba's No Objection on draft-ietf-oauth-token-exchange-18: (with COMMENT)

[Brian Campbell]

That works for me.

On Sat, Jul 20, 2019 at 10:28 PM Benjamin Kaduk  wrote:

> On Fri, Jul 19, 2019 at 10:05:57AM -0600, Brian Campbell wrote:
> > On Fri, Jul 19, 2019 at 8:31 AM Barry Leiba 
> wrote:
> >
> > >
> > > >> — Section 1.1 —
> > > >> Given the extensive discussion of impersonation here, what strikes
> me as
> > > >> missing is pointing out that impersonation here is still controlled,
> > > that “A is
> > > >> B” but only to the extent that’s allowed by the token.  First, it
> might
> > > be
> > > >> limited by number of instances (one transaction only), by time of
> day
> > > (only for
> > > >> 10 minutes), and by scope (in regard to B’s address book, but not
> B’s
> > > email).
> > > >> Second, there is accountability: audit information still shows that
> the
> > > token
> > > >> authorized acting as B.  Is that not worth clarifying?
> > > >
> > > > My initial response was going to be "sure, I'll add some bits in sec
> 1.1
> > > along those lines to clarify
> > > > that." However, as I look again at that section for good
> opportunities
> > > to make such additions, I feel
> > > > like it is already said that impersonation is controlled.
> > > ...
> > > > So I think it already says that and I'm gonna have to flip it back
> and
> > > ask if you have concrete
> > > > suggestions for changes or additions that would say it more clearly
> or
> > > more to your liking?
> > >
> > > It is mentioned, true, and that might be enough.  But given that Eve
> > > also replied that she would like more here, let me suggest something,
> > > the use of which is entirely optional -- take it, don't take it,
> > > modify it, riff on it, ignore it completely, as you think best.  What
> > > do you think about changing the last sentence of the paragraph?: "For
> > > all intents and purposes, when A is impersonating B, A is B within the
> > > rights context authorized by the token, which could be limited in
> > > scope or time, or by a one-time-use restriction."
> > >
> >
> > Sure, I think that or some slight modification thereof can work just
> fine.
> > I'll do that and get it and the rest of these changes published when the
> > I-D submission embargo is lifted for Montreal.
>
> My brain is apparntly storming and not sleeping.  Another option for
> consideration, is to have two sentences:
>
> For all intents and purposes, when A is impersonating B, A is B within the
> rights context authorized by the token.  A's ability to impersonate B could
> be limited in scope or time, or even with a one-time-use restriction,
> whether via the contents of the token or an out-of-band mechanism.
>
> -Ben
>

-- 
_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] AD Review: draft-ietf-oauth-resource-indicators-02

[Brian Campbell]

Thanks Roman,

I'm attempting to bring this thread and our private exchanges together
(sorry again that it ended up that way) and make sure we are on the same
page about the path forward before I start down that path.

Yes, your assessment below is correct. And yes I think the changes you
proposed to IANA section 4 of draft-ietf-oauth-resource-indicators follow
from that and make sense.

However, draft-ietf-oauth-token-exchange should also be changed to take on
a short sentence in its text about the resource parameter to mention
draft-ietf-oauth-resource-indicators and include an informational reference
to it.

Please confirm that or correct me and I'll proceed with the changes.



On Wed, Jul 17, 2019 at 5:49 PM Roman Danyliw  wrote:

> Hi Brian!
>
>
>
> Thanks for this background and explanation.  There was history here I
> didn’t know.
>
>
>
> With the benefit of this thread and private exchanges, the key takeaways
> for me are:
>
>
>
> ** the definition of 'resource' for 'token exchange' is identical in both
> drafts (draft-ietf-oauth-resource-indicator and
> draft-ietf-oauth-token-exchange)
>
>
>
> ** draft-ietf-oauth-resource-indicators has additional “uses” of resource
> not germane to draft-ietf-oauth-resource-indicator
>
>
>
> ** the desired ends-state after the IANA considerations sections of both
> drafts were process, the Oauth registry would look as follows:
>
> - name = resource
>
> - parameter usage location = authorization request, token request
>
> - change controller = IETF
>
> - reference = draft-ietf-oauth-resource-indicator
>
>
>
> Is that right?
>
>
>
> If the above is correct, would the following way ahead work:
>
>
>
> ** for draft-ietf-oauth-token exchange: Nothing
>
>
>
> ** for draft-ietf-oauth-resource-indicator
>
>
>
> Per Section 4.1:
>
>
>
>This specification updates the following value in the IANA "OAuth
>
>Parameters" registry [IANA.OAuth.Parameters] established by
>
>[RFC6749].
>
>
>
>o  Parameter name: resource
>
>o  Parameter usage location: authorization request, token request
>
>o  Change controller: IESG
>
>o  Specification document(s): [[ this specification ]]
>
>
>
> Per Section 4.2
>
>This specification updates the following error in the IANA "OAuth
>
>Extensions Error Registry" [IANA.OAuth.Parameters] established by
>
>[RFC6749].
>
>
>
>o  Error name: invalid_target
>
>o  Error usage location: implicit grant error response, token error
>
>   response
>
>o  Related protocol extension: resource parameter
>
>o  Change controller: IESG
>
>o  Specification document(s): [[ this specification ]]
>
>
>
> Roman
>
>
>
>
>
> *From:* Brian Campbell [mailto:bcampb...@pingidentity.com]
> *Sent:* Wednesday, July 17, 2019 6:31 PM
> *To:* Roman Danyliw 
> *Cc:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] AD Review:
> draft-ietf-oauth-resource-indicators-02
>
>
>
> Yeah, as you surmised, there is some history behind this. Basically
> draft-ietf-oauth-token-exchange predates
> draft-ietf-oauth-resource-indicators by a good long time (years) and with
> the hope and expectation that draft-ietf-oauth-token-exchange would move to
> RFC, I've avoided having a reference in it to a draft much earlier along in
> the whole process. draft-ietf-oauth-resource-indicators has a bit of an odd
> history too in that an initial call for adoption around the Buenos Aires
> meeting kinda fizzled out and it was left for dead until being unexpected
> resurrected around Montreal last year due to renewed interest and other
> factors I'm still not sure I understand.
>
>
>
> You are correct that draft-ietf-oauth-token-exchange defines "resource"
> for token exchange. However the registry itself doesn't have that level of
> granularity. It has authorization request, authorization response, token
> request, and token response as the possible locations for parameter usage..
> A token exchange request is a particular kind of token request so
> draft-ietf-oauth-token-exchange registers "resource" for the token request
> location. The IANA section was written before
> draft-ietf-oauth-resource-indicators even existed. And leaving the
> registration in draft-ietf-oauth-token-exchange seemed like the right thing
> to do to even after draft-ietf-oauth-resource-indicators came along. But
> I'm not sure, to be honest. Also FWIW a temporary registration entry for it
> is already in
> https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xh

Re: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-token-exchange-18: (with COMMENT)

[Brian Campbell]

On Fri, Jul 19, 2019 at 8:31 AM Barry Leiba  wrote:

> >> and I trust the authors and responsible AD to do the right thing.
> >
> > I always endeavor to do the right thing.
>
> You do; hence, the trust.  :-)
>

I do appreciate that, thank you.


> And thanks for the quick responses.
>

I try. To varying degrees of success.


>
> >> — Section 1.1 —
> >> Given the extensive discussion of impersonation here, what strikes me as
> >> missing is pointing out that impersonation here is still controlled,
> that “A is
> >> B” but only to the extent that’s allowed by the token.  First, it might
> be
> >> limited by number of instances (one transaction only), by time of day
> (only for
> >> 10 minutes), and by scope (in regard to B’s address book, but not B’s
> email).
> >> Second, there is accountability: audit information still shows that the
> token
> >> authorized acting as B.  Is that not worth clarifying?
> >
> > My initial response was going to be "sure, I'll add some bits in sec 1.1
> along those lines to clarify
> > that." However, as I look again at that section for good opportunities
> to make such additions, I feel
> > like it is already said that impersonation is controlled.
> ...
> > So I think it already says that and I'm gonna have to flip it back and
> ask if you have concrete
> > suggestions for changes or additions that would say it more clearly or
> more to your liking?
>
> It is mentioned, true, and that might be enough.  But given that Eve
> also replied that she would like more here, let me suggest something,
> the use of which is entirely optional -- take it, don't take it,
> modify it, riff on it, ignore it completely, as you think best.  What
> do you think about changing the last sentence of the paragraph?: "For
> all intents and purposes, when A is impersonating B, A is B within the
> rights context authorized by the token, which could be limited in
> scope or time, or by a one-time-use restriction."
>

Sure, I think that or some slight modification thereof can work just fine.
I'll do that and get it and the rest of these changes published when the
I-D submission embargo is lifted for Montreal.



>
> >> — Section 6 —
> >> Should “TLS” here have a citation and normative reference?
> >
> > I didn't include an explicit reference here because TLS is transitively
> referenced by other
> > normative references (including 6749 of which this whole thing is an
> extension) and TLS
> > is pretty widely recognized even without citation.
> ...
> > I'm happy to add a citation here but it does raise the question of what
> the most appropriate
> > way to cite TLS is right now - 1.3, 1.2, or the BCP or some combination
> thereof?
>
> I wondered the same thing, and you're also right that it might not
> need a reference in this document.  I only even flagged it because
> it's the subject of a MUST.  I'll leave it to the Sec ADs (who
> obviously didn't flag it themselves, so maybe they agree that it's not
> necessary).
>

I'm gonna just leave it as-is then, unless I hear otherwise from the Sec
ADs.

-- 
_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] Barry Leiba's No Objection on draft-ietf-oauth-token-exchange-18: (with COMMENT)

[Brian Campbell]

Barry, thanks for the review, ballot position and comments. Please see
inline below for my replies to the latter.


On Thu, Jul 18, 2019 at 3:06 PM Barry Leiba via Datatracker <
nore...@ietf.org> wrote:

> Barry Leiba has entered the following ballot position for
> draft-ietf-oauth-token-exchange-18: No Objection
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/
>
>
>
> --
> COMMENT:
> --
>
> I have comments below, a couple of which might have been DISCUSS except
> that
> there have been enough eyes on this and enough DISCUSSes already, and I
> trust
> the authors and responsible AD to do the right thing.


I always endeavor to do the right thing.



>   So I’ve divided the
> comments between “higher importance” and “purely editorial”.
>
> Of higher importance:
>
> — Section 1.1 —
> Given the extensive discussion of impersonation here, what strikes me as
> missing is pointing out that impersonation here is still controlled, that
> “A is
> B” but only to the extent that’s allowed by the token.  First, it might be
> limited by number of instances (one transaction only), by time of day
> (only for
> 10 minutes), and by scope (in regard to B’s address book, but not B’s
> email).
> Second, there is accountability: audit information still shows that the
> token
> authorized acting as B.  Is that not worth clarifying?
>

My initial response was going to be "sure, I'll add some bits in sec 1.1
along those lines to clarify that." However, as I look again at that
section for good opportunities to make such additions, I feel like it is
already said that impersonation is controlled. Notably there are these bits
of text:

"or for A to
   be granted a *limited access credential *to C but that continues to
   identify B as the authorized entity ("impersonation")."

"When principal A impersonates principal B, A is given all the rights
   that B has *within some defined rights context*"

So I think it already says that and I'm gonna have to flip it back and ask
if you have concrete suggestions for changes or additions that would say it
more clearly or more to your liking?




>
> — Section 8.2 —
> RFC 8174 needs to be normative, along with 2119.
>

Of course. Not sure how those got separated in the first place but I'll
move 8174 to normative.



> — Section 2.2.2 —
>
>If the authorization server is unwilling or unable to issue a token
>for all the target services indicated by the "resource" or "audience"
>parameters, the "invalid_target" error code SHOULD be used in the
>error response.
>
> I always trip when I read “all” in a context like this.  I think you mean
> “any”, because you have “a token”.  You could arguably make it “tokens” and
> leave “all”, but I think changing to “any” is clearer:
>
> NEW
>If the authorization server is unwilling or unable to issue a token
>for any target service indicated by the "resource" or "audience"
>parameters, the "invalid_target" error code SHOULD be used in the
>error response and no tokens are returned.
> END
>
> The danger with “all” is having a reader interpret the error as only
> occurring
> when the server fails *all* services, and thinking that failing one out of
> three still constitutes success.  I have seen this be an issue often (not
> with
> OAuth, but in general).  If you want to be absolutely clear you could even
> add
> to the end, “A request is successful only when all requested tokens are
> issued.”
>

Will change to try and avoid that potential trip-up.




>
> — Section 5 —
>
>In addition, both delegation and impersonation introduce unique
>security issues.  Any time one principal is delegated the rights of
>another principal, the potential for abuse is a concern.  The use of
>the "scope" claim is suggested to mitigate potential for such abuse,
>as it restricts the contexts in which the delegated rights can be
>exercised.
>
> I’m ambivalent here: is it worth also mentioning limiting the time a token
> is
> valid and possibly make it a one-time-use token?  Or is it that that’s
> adequately covered in the other references and shouldn’t be repeated here?
>
> Also, is it worth referring (not copying) here to the advice in section 2..1
> about the importance of authentication?
>
> — Section 6 —
> Should “TLS” here have a citation and normative reference?
>

I didn't include an explicit reference here because TLS is transitively
referenced by other normative references (including 6749 of which this
whole thing is an extension) and TLS is pretty widely recognized even
without citation.

Or maybe it was just an oversight when I added that particular text.

I'm happy to add a citation here but it does raise the question of what the
most appropriate way to cite TLS is right now - 1.3, 1.2, or the B

Re: [OAUTH-WG] IETF105 OAuth WG Draft Agenda

[Brian Campbell]

I'd also be interested.



On Wed, Jul 17, 2019 at 12:47 PM Mike Jones  wrote:

> I’d be interested in hearing that presentation – particularly the
> “lessons” part.
>
>
>
>-- Mike
>
>
>
> *From:* OAuth  *On Behalf Of * Richard Backman,
> Annabelle
> *Sent:* Wednesday, July 17, 2019 11:28 AM
> *To:* Dick Hardt ; Rifaat Shekh-Yusef <
> rifaat.i...@gmail.com>
> *Cc:* oauth 
> *Subject:* Re: [OAUTH-WG] IETF105 OAuth WG Draft Agenda
>
>
>
> I’m coming in late to this party, but I’ve been asked by a few people
> about how AWS handles request signing and our experiences with it. Given
> the renewed interest in HTTP request signing and the ongoing work on DPoP,
> is this something the working group would be interested in hearing about
> during one of the sessions? I could put together a quick 5-10 minute
> overview of AWS SigV4 signing and some of the lessons that went into its
> design.
>
>
>
> Thoughts?
>
>
>
> --
>
> Annabelle Richard Backman
>
> AWS Identity
>
>
>
>
>
> *From: *OAuth  on behalf of Dick Hardt <
> dick.ha...@gmail.com>
> *Date: *Wednesday, July 10, 2019 at 3:20 PM
> *To: *Rifaat Shekh-Yusef 
> *Cc: *oauth 
> *Subject: *Re: [OAUTH-WG] IETF105 OAuth WG Draft Agenda
>
>
>
> +1
>
>
>
> I like it! :)
>
>
>
> On Wed, Jul 10, 2019 at 3:17 PM Rifaat Shekh-Yusef 
> wrote:
>
> All,
>
>
>
> Here is our draft agenda for the two sessions we have planned for Montreal:
>
> https://datatracker.ietf.org/meeting/105/materials/agenda-105-oauth-00
> 
>
>
>
>
> Please, take a look and let us know if you have any comments.
>
>
>
> Regards,
>
>  Rifaat & Hannes
>
>
>
> ___
> 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] AD Review: draft-ietf-oauth-resource-indicators-02

[Brian Campbell]

Yeah, as you surmised, there is some history behind this. Basically
draft-ietf-oauth-token-exchange predates
draft-ietf-oauth-resource-indicators by a good long time (years) and with
the hope and expectation that draft-ietf-oauth-token-exchange would move to
RFC, I've avoided having a reference in it to a draft much earlier along in
the whole process. draft-ietf-oauth-resource-indicators has a bit of an odd
history too in that an initial call for adoption around the Buenos Aires
meeting kinda fizzled out and it was left for dead until being unexpected
resurrected around Montreal last year due to renewed interest and other
factors I'm still not sure I understand.

You are correct that draft-ietf-oauth-token-exchange defines "resource" for
token exchange. However the registry itself doesn't have that level of
granularity. It has authorization request, authorization response, token
request, and token response as the possible locations for parameter usage.
A token exchange request is a particular kind of token request so
draft-ietf-oauth-token-exchange registers "resource" for the token request
location. The IANA section was written before
draft-ietf-oauth-resource-indicators even existed. And leaving the
registration in draft-ietf-oauth-token-exchange seemed like the right thing
to do to even after draft-ietf-oauth-resource-indicators came along. But
I'm not sure, to be honest. Also FWIW a temporary registration entry for it
is already in
https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#parameters

draft-ietf-oauth-resource-indicators defines "resource" for use at the
authorization endpoint (which token exchange does not) so that's the
impetus behind having the registration request there include authorization
request in the location. draft-ietf-oauth-resource-indicators also has
"resource" for use at the token endpoint using the same semantics as in
draft-ietf-oauth-token-exchange but in a way that is applicable to all
types of token requests to the the token endpoint and not only token
exchange requests. That's where the idea of updating the registry came from
- it's not a name collision and it's not a different definition - it's just
a more generalized usage.

I hope this makes some sense and hasn't muddied the waters more.



On Wed, Jul 17, 2019 at 3:13 PM Roman Danyliw  wrote:

> Hi!
>
> I forgot one more thing about this draft after re-reading
> draft-ietf-oauth-token-exchange.
>
> Per the IANA action in Section 4.1, I need help understanding on the
> thinking to resolve this TODO:
>
>o  Parameter usage location: authorization request, token request
>   [[TODO: draft-ietf-oauth-token-exchange will have already
>   registered this for 'token request' and this draft has a more
>   generalized usage and needs to somehow either update that
>   registration or do a partial registration and reference]]
>o  Change controller: IESG
>o  Specification document(s): [[ this specification ]]
>
> My read of draft-ietf-oauth-token-exchange it that it defines 'resource'
> for 'token exchange'.  This draft (draft-ietf-oauth-resource-indicators)
> has guidance on 'resource' for 'authorization request' but also additional
> guidance for 'token request'.  Is the token guidance request stated here
> applicable to draft-ietf-oauth-token-exchange too (i.e., is the text
> effectively saying oauth-resource-indicators updates oauth-token-exhange)?
> I ask because these drafts don't reference each other.
>
> Correct me because there is likely a history, but it seems the TODO is
> that there is a dependency to resolve and a need to coming up with a way to
> signal in the registry which draft should be read for what usage location..
> Could draft-ietf-oauth-resource-indicators officially register 'resource';
> and instead of draft-ietf-oauth-token-exchange including the text defining
> 'resource' in Section 2.1, it would make a normative reference to Section 2
> of draft-ietf-oauth-resource-indicators?
>
> Roman
>
> > -Original Message-
> > From: Roman Danyliw
> > Sent: Tuesday, July 16, 2019 7:23 PM
> > To: oauth@ietf.org
> > Subject: AD Review: draft-ietf-oauth-resource-indicators-02
> >
> > Hi!
> >
> > The following is my AD review of draft-ietf-oauth-resource-indicators-02.
> > The document is in good shape.
> >
> > (1) Section 2. Per "The parameter can carry the location of a protected
> > resource, typically as an https URL, or a more abstract identifier", is
> this
> > "abstract identifier" still an absolute URI per Section 4.3 of RFC3986?
> >
> > (2) Section 2.2.  in the sentence "To the extent possible, when issuing
> access
> > tokens, the authorization server should adapt the scope value associated
> > with an access token to the value the respective resource is able to
> process
> > and needs to know":
> >
> > --  is this language suggesting that the authorization server is
> modifying the
> > scope value based on the resource it sees?  I'm trying to understand

Re: [OAUTH-WG] AD Review: draft-ietf-oauth-resource-indicators-02

[Brian Campbell]

Thank you, Roman, for the review. Some replies are inline below. I'll aim
to push out a -03 addressing this stuff sometime not too long after the I-D
submission embargo is lifted next week.


On Tue, Jul 16, 2019 at 5:23 PM Roman Danyliw  wrote:

> Hi!
>
> The following is my AD review of draft-ietf-oauth-resource-indicators-02.
> The document is in good shape.
>

That's always nice to hear :-)


>
> (1) Section 2. Per "The parameter can carry the location of a protected
> resource, typically as an https URL, or a more abstract identifier", is
> this "abstract identifier" still an absolute URI per Section 4.3 of RFC3986?
>

Absolutely (see what I did there? sigh...). Syntactically it's an absolute
URI. Semantically, while it might be an actual network addressable location
identified by an HTTPS URL, it might also be a URN or something that more
abstractly indicates a resource or grouping of resources. But its format is
an absolute URI regardless.

I'm not sure what, if anything, can be added or changed here to help
clarify. But I'm happy to entertain suggestions, if you've got em and/or
think something is needed.



> (2) Section 2.2.  in the sentence "To the extent possible, when issuing
> access tokens, the authorization server should adapt the scope value
> associated with an access token to the value the respective resource is
> able to process and needs to know":
>
> --  is this language suggesting that the authorization server is modifying
> the scope value based on the resource it sees?  I'm trying to understand
> what "adapt" means, especially in relation to the improved security and
> privacy the subsequent sentence suggests.
>

Perhaps "adapt" wasn't the best choice of word but it's meant to say that
an authorization server with sufficient understanding of what scopes are
applicable to what resources (which won't always be the case or even
possible but sometimes) could limit the scope associated with an access
token (downscoping really) to only the scope that is applicable to the
resource.

Some of the examples (figures 2 - 6) attempt to show, among other things, a
hypothetical case of how this might go down.

In Figure 2 the initial authorization request that's approved has scope of
calendar & contacts and resources https://contacts.example.com/ &
https://cal.example.com/

A subsequent access token request (Figure 3) has resource
https://cal.example.com/ and the issued access token scope (Figure 4) is
"adapted" to that resource to be only calendar

Another subsequent access token request (Figure 5) has resource
https://contacts.example.com/ and the issued access token scope (Figure 6)
is downscoped based on that resource to be only contacts

Would it be easier to understand if the word "downscope" was used rather
than "adapt"?



>
> -- (Depending on the above) Is there a security consideration here for the
> server relative to confidential scope values and how they might be modified?
>

I'm not sure, to be honest. Downscopping when possible and to the extent
possible is usually a good idea (least privilege and all that) but I think
maybe I'm missing your point/question.



>
> (3) Editorial
> ** Section 1 and 2.1.  Multiple Typo.  s/the the/the/g
>

Apparently I'm fond of the double "the" and have a hard time spotting it
myself. I think this is the second review in as many weeks that you've
caught a few of those. Will fix.


>
> ** Section 2.  Editorial. s/resource at which/resource to which/
>

Okay.


>
> ** Section 2.  Editorial.
> s/ And can also be used to inform the client that it has requested an
> invalid combination of resource and scope./
> It can also be used to inform the client that it has requested an
> invalid combination of resource and scope./
>

Yup.


>
> ** Section 2.1. Multiple Typo. s/an an/an/g
>

Again with the double words. Sigh. A double double even.



> ** Section 2.2.  Editorial. s/token request and response/token request
> (Figure 3) and response (Figure 4)/
>

Makes sense.



> ** Section 3.  Typo.  s/a invalid/an invalid/
>

Of course.


>
> ** Section 3.  Missing words.  "A bearer token that has multiple intended
> recipients (audiences) can be used by any one of those recipients at any
> other."  Is it protected resource?
>

Well, those are all the words that I'd intended to be there :/ But it does
read a little curtly. How about the following instead?

"A bearer token that has multiple intended recipients (audiences)
indicating that the token is valid at more than one protected resource can
be used by any one of those protected resources to access any of the other
protected resources."

-- 
_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 you

Re: [OAUTH-WG] Benjamin Kaduk's Yes on draft-ietf-oauth-token-exchange-17: (with COMMENT)

[Brian Campbell]

I believe there's a fair amount of precedent for something like it but
typically it's indicating group membership or roll(s) of a user that's
uniquely identified by other claims in a JWT. And, as far as I know,
there's nothing standardized for it so it's done more ad hoc. Thus there's
not really precedent from a standards perspective and, as I think about it
more, it's probably not a terribly good idea to try and define new
semantics like that at the 11th hour. So I'm gonna go with the '1) leave it
as is' option. And you're right that there are things that could be done
without too much issue, should it ever prove to be an issue (which I kinda
don't think will happen anyway).



On Fri, Jul 12, 2019 at 7:13 PM Benjamin Kaduk  wrote:

> On Sun, Jul 07, 2019 at 09:32:15AM -0400, Brian Campbell wrote:
> > On Sat, Jul 6, 2019 at 2:42 PM Benjamin Kaduk  wrote:
> >
> > >
> > > > Not to my recollection. I'm honestly not even sure what an array
> would
> > > mean
> > > > for "may_act". Do you mean for "act"?
> > >
> > > Currently we can say that ad...@example.com "may act" as
> u...@example.com.
> > > But IIUC we don't have a way to say that either adm...@example.com or
> > > adm...@example.com may do so.  An array would let us indicate multiple
> > > authorized parties.  I'm reluctant to actually make such a change at
> this
> > > point, though, since this is already deployed some places, right?
> > >
> >
> > Okay, sorry, I'm a bit slow but I follow you now.
> >
> > Indeed this has been deployed in a number of places already. I'd honestly
> > don't know if anyone is making use of this particular claim but changing
> > from an object to array of objects would be a breaking change. And a
> > breaking change is something I'd really like to avoid unless there's a
> very
> > compelling reason to do so.  And while your point here is taken, I don't
> > think it rises to that level of compelling.
> >
> > I see two options at this point:
> > 1) leave it as is
> > 2) adjust the language around  "may_act" such that it could also identify
> > an eligible group - this would allow for it to indicate multiple
> authorized
> > parties but just not by one by one name, which is maybe more desirable
> > anyway
> >
> > What do you think?
>
> Either option is fine with me.  I don't remember how much precedent we have
> in the OAuth ecosystem for groups that are  identified in  this manner, but
> if it's a fairly common thing that seems to be slighly preferred.
> (Even if we go with (1) and this does become an issue at some point, it
> shouldn't be too hard to add a "may_also_act" or similar with the array
> semantics.)
>
> -Ben
>

-- 
_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] Benjamin Kaduk's Yes on draft-ietf-oauth-token-exchange-17: (with COMMENT)

[Brian Campbell]

On Sat, Jul 6, 2019 at 2:42 PM Benjamin Kaduk  wrote:

>
> > Not to my recollection. I'm honestly not even sure what an array would
> mean
> > for "may_act". Do you mean for "act"?
>
> Currently we can say that ad...@example.com "may act" as u...@example.com..
> But IIUC we don't have a way to say that either adm...@example.com or
> adm...@example.com may do so.  An array would let us indicate multiple
> authorized parties.  I'm reluctant to actually make such a change at this
> point, though, since this is already deployed some places, right?
>

Okay, sorry, I'm a bit slow but I follow you now.

Indeed this has been deployed in a number of places already. I'd honestly
don't know if anyone is making use of this particular claim but changing
from an object to array of objects would be a breaking change. And a
breaking change is something I'd really like to avoid unless there's a very
compelling reason to do so.  And while your point here is taken, I don't
think it rises to that level of compelling.

I see two options at this point:
1) leave it as is
2) adjust the language around  "may_act" such that it could also identify
an eligible group - this would allow for it to indicate multiple authorized
parties but just not by one by one name, which is maybe more desirable
anyway

What do you think?

-- 
_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] Benjamin Kaduk's Yes on draft-ietf-oauth-token-exchange-17: (with COMMENT)

[Brian Campbell]

Thanks Ben, I'll publish an -18 shortly with these suggestions. A bit more
detail is inline below.


On Fri, Jul 5, 2019 at 11:57 PM Benjamin Kaduk via Datatracker <
nore...@ietf.org> wrote:

>
> --
> COMMENT:
> --
>
> I'm balloting Yes; this document is solid and well-written.


Thanks!


  I do have a
> few additional (largely editorial) suggestions and a question or two,
> though.
>
> Section 2.1
>
>The client makes a token exchange request to the token endpoint with
>an extension grant type using the HTTP "POST" method and including
>the following parameters using the "application/x-www-form-
>urlencoded" format with a character encoding of UTF-8 in the HTTP
>request entity-body as described in Appendix B of RFC6749 [RFC6749].
>
> This is a really long sentence.  I see how it got that way, and the RFC
> Editor staff will probably have some thoughts on how to reword it, but
> if you happen to have thoughts as well, feel free to have at it.
>

I had at it a little bit and broke it up into two sentences.



>
> Section 2.2.1
>
>expires_in
>   RECOMMENDED.  The validity lifetime, in seconds, of the token
>   issued by the authorization server.  Oftentimes the client will
>   not have the inclination or capability to inspect the content of
>   the token and this parameter provides a consistent and token type
>   agnostic indication of how long the token can be expected to be
>   valid.  For example, the value 1800 denotes that the token will
>
> nit: hyphenate "token-type-agnostic".
>

done



> Section 4.4
>
> Refresh my memory: did we already have a discussion about may_act as an
> object vs. an array of objects?
>

Not to my recollection. I'm honestly not even sure what an array would mean
for "may_act". Do you mean for "act"? I suppose an array of objects could
be used as the value of "act" as a way to express a chain of delegation.
However, the object with optional nesting seemed (to me) a more natural way
to express it and has no overhead for the likely most common case of just a
single actor.




>
> Section 5
>
> I'd consider also mentioning/linking the OAuth 2.0 security
> considerations -- the fact that the STS is colocated with the token
> endpoint takes care of ensuring a lot of its security properties.
>

Makes sense. I'll add that. And refs to RFC6819 and
draft-ietf-oauth-security-topics to round it out.



> Section 7
>
> It's common (but not required, since it will not be relevant upon
> publication as an RFC) to note that the indicated values are reflected
> in early allocations from the indicated IANA registries.  In this case
> I'd say "don't bother"...
>

Not bothering...



> Appendix B
>
> Uh-oh, now we are up to five security ADs that have been around for this
> document...
>

 an oversight on my part and unfortunate reminder about just how long
this document has been in progress.

I'll add Roman.

-- 
_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] Adam Roach's Discuss on draft-ietf-oauth-token-exchange-16: (with DISCUSS and COMMENT)

[Brian Campbell]

Adam,

I went ahead and assumed that your silence constituted acceptance of the
proposal to use RFC6749's Appendix B. on the "Use of
application/x-www-form-urlencoded Media Type" as a citation for the media
type. So I added that bit and also fixed the other nits you identified in
-17 https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-17. As
such, I'd respectfully request that you review the changes and clear the
discuss.

Thank you,
Brian


On Wed, Nov 28, 2018 at 8:19 AM Brian Campbell 
wrote:

> Thank you for the review, Adam. I do sincerely hope that your time with
> the document didn't drive you to drink (too much anyway). Please see below
> for inline comments/responses.
>
> On Tue, Nov 20, 2018 at 4:39 PM Adam Roach  wrote:
>
>> Adam Roach has entered the following ballot position for
>> draft-ietf-oauth-token-exchange-16: Discuss
>>
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/
>>
>>
>>
>> --
>> DISCUSS:
>> --
>>
>> Thanks to everyone who worked on this document. I have a blocking issue
>> that
>> should be easy to resolve, and a handful of more minor issues.
>>
>> §2.1:
>>
>> >  The client makes a token exchange request to the token endpoint with
>> >  an extension grant type by including the following parameters using
>> >  the "application/x-www-form-urlencoded" format
>>
>> This document needs a normative citation for this media type.
>>
>> My suggestion would be to cite REC-html5-20141028 section 4.10.22.6, as
>> this
>> appears to be the most recent stable description of how to encode this
>> media
>> type. I'd love to hear rationale behind other citations being more
>> appropriate,
>> since I'm not entirely happy with the one I suggest above (given that
>> it's been
>> superseded by HTML 5.2); but every other plausible citation I can find is
>> even
>> less palatable (with HTML 5.2 itself having the drawback of not actually
>> defining how to encode the media type, instead pointing to an unstable,
>> unversioned document).
>>
>
> What about a pointer to RFC6749's Appendix B. on the "Use of
> application/x-www-form-urlencoded Media Type"
> <https://tools.ietf.org/html/rfc6749?#appendix-B>? I had admittedly
> forgot about it until looking back at the original OAuth 2.0 document as a
> result of you raising this DISCUSS to see what citation was used there.
>
> Despite citing an older HTML document I think the few paragraphs there do
> a nice job of explaining the situation in a pragmatic and actionable way.
> And as the original OAuth 2.0 Authorization Framework is responsible for
> the use of "application/x-www-form-urlencoded" in extensions like this
> token exchange, it seems fitting to point back to it.
>
> I'm happy to cite REC-html5-20141028 section 4.10.22.6, if you feel that's
> more appropriate. But wanted to throw that other idea out there to see if
> you find that any more palatable.
>
>
>
>>
>> --
>> COMMENT:
>> --
>>
>> Abstract:
>>
>> >  This specification defines a protocol for an HTTP- and JSON- based
>>
>> Nit: "...JSON-based..."
>>
>>
> Will fix.
>
>
>
>>
>> ---
>>
>> §1.1:
>>
>> >  impersonates principal B, then in so far as any entity receiving such
>>
>> Nit: "insofar"
>>
>>
> This will be fixed insofar as you are right.
>
>
> ---
>>
>> §2.1:
>>
>> >  The client makes a token exchange request to the token endpoint with
>> >  an extension grant type by including the following parameters using
>> >  the "application/x-www-form-urlencoded" format with a character
>> >  encoding of UTF-8 in the HTTP request entity-body:
>>
>> I think there's an implication here that POST is used, but that probably
>> needs
>> to be made explicit.
&

Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-token-exchange-16: (with DISCUSS and COMMENT)

[Brian Campbell]

Ben,

It took more time than expected but the early registry allocations have
been approved and completed. They can all be found (qualified as
'TEMPORARY') at https://www.iana.org/assignments/oauth-parameters and
https://www.iana.org/assignments/jwt

I've also published draft -17 of the document
https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-17 with changes
that believe (or hope anyway) address all of your comments. As such, I'd
respectfully request that you review the changes and clear the discuss.

Thank you,
Brian




On Sat, Jan 19, 2019 at 8:58 AM Brian Campbell 
wrote:

> This response is slow but somewhat less slow than those that came before.
> So I also apologize again but somewhat less so :)  I do apologize for
> sending on a weekend but I just wasn't able to finish and make it to the
> "send" button before the end of my Friday.
>
> I've endeavored to continue the exchange inline below where appropriate
> and removed portions that needed no further discussion.
>
>
> On Fri, Jan 11, 2019 at 9:13 AM Benjamin Kaduk  wrote:
>
>> I also apologize for the slow response (I gave Brian a unicast heads-up
>> earlier) -- between vacation, the holidays, and a death in a the family I
>> was away from email for quite some time.
>>
>> On Tue, Dec 04, 2018 at 02:54:36PM -0700, Brian Campbell wrote:
>> > I apologize for the slow response, Ben. I was on vacation with my family
>> > around the Thanksgiving holiday when the ballot position came in. And
>> even
>> > on returning and starting to work on it, there's an awful lot here to
>> get
>> > through and this kind of thing is very time consuming for me. But thank
>> you
>> > for the review - I've attempted to reply, as best I can, to your
>> > comments/questions inline below.
>> >
>> > On Wed, Nov 21, 2018 at 6:43 AM Benjamin Kaduk  wrote:
>> >
>> > > Benjamin Kaduk has entered the following ballot position for
>> > > draft-ietf-oauth-token-exchange-16: Discuss
>> > >
>> > > Please refer to
>> https://www.ietf.org/iesg/statement/discuss-criteria.html
>> > > for more information about IESG DISCUSS and COMMENT positions.
>> > >
>> > >
>> > > The document, along with other ballot positions, can be found here:
>> > > https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/
>> > >
>> > > --
>> > > DISCUSS:
>> > > --
>> > >
>>  
>>
>> There's two obvious routes -- first, to change the text to use
>> placeholders
>> like "TBD1" or "the token-exchange URI" (e.g., as opposed to
>> urn:ietf:params:oauth:grant-type:token-exchange specifically) and request
>> that IANA allocate the specific suggested values; or
>> to get IANA to explicitly confirm that
>> these values can be registered and will be marked as pending until this
>> document is finalized (to prevent allocation "under our nose" by other
>> means).  Ekr and I can help mediate any IANA interaction needed for
>> whatever route we end up taking, if needed.
>>
>> (Basically, this is a process concern -- the IESG should not give its
>> stamp
>> of approval to a document in a state that does something we don't want
>> other people to do, even if the final published RFC will be able to make
>> these claims correctly.)
>>
>
> I'd then ask that the AD(s) initiate and mediate interactions with IANA to
> have them explicitly confirm that these values can be registered and have
> them somehow marked as pending until the document is finalized.
>
>
>
>
>> >
>>  
>>
>> Before I start trying to tweak text, can you confirm that the actor_token
>> request parameter is okay to use in both delegation and impersonation
>> scenarios?
>>
>
> Yes, it's certainly okay to use the actor_token in both delegation and
> impersonation scenarios. It's necessary for delegation and kinda makes more
> sense in that scenario but could still be sent by the client and have the
> STS issue a new token with impersonation semantics.
>
>
>
>
>> > >
>> > > Are the privacy considerations (e.g., risk of a tailed per-request
>> > > error_uri) relating to the use of error_uri discussed in some other
>> > > document that we can refer to from this document's security
>> > > considerations?  (I say a

Re: [OAUTH-WG] Alissa Cooper's Discuss on draft-ietf-oauth-token-exchange-16: (with DISCUSS and COMMENT)

[Brian Campbell]

Alissa,

Having not heard anything more on the issue, I went ahead and made those
changes to the Privacy Consideration section. I believe they address the
question/concern in your DISCUSS ballot. As such, I'd respectfully request
that you review the changes and clear the discuss.

Thank you,
Brian

On Wed, Nov 28, 2018 at 1:38 PM Brian Campbell 
wrote:

> Thank you, Alissa, for the review. Please see below for inline
> comments/responses and note that this is also my response to your last
> message on the related thread at
> https://mailarchive.ietf.org/arch/msg/oauth/MKqEIsb8TJCFUNl3vF-bB38nWv4
>
>
> On Tue, Nov 20, 2018 at 12:50 PM Alissa Cooper  wrote:
>
>> Alissa Cooper has entered the following ballot position for
>> draft-ietf-oauth-token-exchange-16: Discuss
>>
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/
>>
>>
>>
>> --
>> DISCUSS:
>> --
>>
>> Section 6: The requirements around confidentiality here are weaker than
>> in both
>> RFC 7519 Sec. 12 and RFC 6749 Sec. 10.8. Why?
>>
>
> I think the why of it is some unintentional drift in the language along
> with my general reluctance in using the 2119 words out of a fear of
> overusing them (which I'm admittedly inconsistent about but it certainly
> manifested itself in this text).
>
> They should all say basically the same thing, which was really the intent,
> if the actual wording didn't end up that way.
>
> I think that changing a few of the little shoulds to big MUSTs or SHOULDs
> would bring the requirements around confidentiality here in line with RFC
> 7519 Sec. 12 and RFC 6749 Sec. 10.8.. That updated text would be as
> follows. Would this address your question/concern?
>
>Tokens employed in the context of the functionality described herein
>may contain privacy-sensitive information and, to prevent disclosure
>of such information to unintended parties, MUST only be transmitted
>over encrypted channels, such as Transport Layer Security (TLS).  In
>cases where it is desirable to prevent disclosure of certain
>information to the client, the token MUST be encrypted to its
>intended recipient.  Deployments SHOULD determine the minimally
>necessary amount of data and only include such information in issued
>tokens.  In some cases, data minimization may include representing
>only an anonymous or pseudonymous user.
>
>
>
>> --
>> COMMENT:
>> --
>>
>> Section 3:
>>
>> If I understand this correctly:
>>
>> "The distinction between an access token and a JWT is subtle."
>>
>> I think it would be clearer if it said:
>>
>> "The distinction between an access token type and a JWT token type is
>> subtle."
>>
>
> In that sentence and paragraph I'm really meaning to talk about the things
> themselves (access tokens and JWTs) rather than the type, which is more
> like a way of naming those things. I don't think it's necessarily wrong
> either way but my intention in writing is better reflected in the current
> text. Furthermore, when the acronym in "JWT token" is expanded you get
> "JSON Web Token token", which is something I'd like to avoid having in the
> document.
>
>
>
>> Section 4.1:
>>
>> What is the value of maintaining the whole delegation chain rather than
>> expressing just the most recent delegation? Doesn't it potentially expose
>> information about past exchanges unnecessarily?
>>
>
> There's value, in some situations, to being able to see/track the whole
> delegation chain - primarily for auditing and troubleshooting type purposes
> and typically when the parties in the chain are under the same domain of
> organizational control where allowing that information to be available
> isn't a concern but rather a benefit.
>
> And, of course, there's no requirement that the whole delegation chain be
> maintained. The syntax and structure of the claim allows for the info to be
> represented when appropriate but doesn't mean that it has to be.
>
>
>

-- 
_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] Second AD Review: draft-ietf-oauth-mtls

[Brian Campbell]

Okay, -15 has been published and incorporates those fixes and suggestions:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-mtls-15

On Mon, Jun 24, 2019 at 5:04 PM Brian Campbell 
wrote:

> Thanks Roman, I'll work to incorporate those suggestions into the next
> revision before the impending I-D submission cutoff date.
>
> On Mon, Jun 24, 2019 at 2:14 PM Roman Danyliw  wrote:
>
>> Hi Brian!
>>
>>
>>
>> My response is inline ...
>>
>>
>>
>> *From:* Brian Campbell [mailto:bcampb...@pingidentity.com]
>> *Sent:* Monday, June 24, 2019 1:17 PM
>> *To:* Roman Danyliw 
>> *Cc:* oauth 
>> *Subject:* Re: [OAUTH-WG] Second AD Review: draft-ietf-oauth-mtls
>>
>>
>>
>> Thanks for the additional review, Roman. I feel lucky, it's not often one
>> gets *two* AD reviews :)  Please see below for replies inline with a few
>> followup questions.
>>
>>
>>
>> [Roman] *chuckle*
>>
>>
>>
>> On Sat, Jun 22, 2019 at 12:29 PM Roman Danyliw  wrote:
>>
>> Hi!
>>
>> I conducted as second AD review of draft-ietf-oauth-mtls per the AD
>> hand-off.  I have the following additional feedback:
>>
>> ** Per ekr's earlier review at
>> https://mozphab-ietf.devsvcdev.mozaws.net/D3657, paraphrasing:
>> -- Section 2.1.2, How is these metadata parameters being obtained?
>>
>>
>>
>> The authorization server can obtain client metadata via the Dynamic
>> Client Registration Protocol [RFC7591], which is referenced in the top of
>> that section. Also the metadata defined by RFC7591, and registered
>> extensions to it, implies a general data model for clients that is used by
>> most authorization server implementations even when the Dynamic Client
>> Registration Protocol isn't in play. Such implementations typically have
>> some sort of  user interface available for managing client configuration..
>>
>>
>>
>> Dose that answer your question? Do you believe more should be said in the
>> document to better explain or clarify that?
>>
>>
>>
>> [Roman]  It does clear it up.  Thanks.  I think it’s worth a short
>> statement about how the AS would get the fields.
>>
>>
>>
>>
>>
>> -- Section 3.2, Figure 3.  In this example, what new information is the
>> auth server providing to the relying party here?
>>
>>
>>
>> The new info here (and in Section 3.1 too) is the hash of the client
>> certificate to which the access token is bound, which is in the "cnf"
>> confirmation method at the bottom as the "x5t#S256" member.
>>
>>
>>
>> [Roman]  Makes sense.  To make the example clearer, I’d call out this out
>> in the prose introducing the example.
>>
>>
>>
>>
>> ** Section 2.0.  What is the expected behavior if the presented
>> certificate doesn't match expected client_id?  How is this signaled?
>>
>>
>>
>> With a normal OAuth 2.0 error response using the "invalid_client" error
>> code per https://tools.ietf.org/html/rfc6749#section-5.2
>>
>>
>>
>> Do you think that needs to be stated more explicitly in this document?
>>
>>
>>
>> [Roman] Yes, I’d explicit state it with that citation, especially since
>> Section 3 discusses of how errors are returned.
>>
>>
>>
>>
>> ** Section 2.2.  Per the sentence "As pre-requisite, the client registers
>> its X.509 certificate ... or a trusted source for its X.509 certificates
>> ... with the authorization server.
>> -- Editorial: s/As pre-requisite/As a prerequisite/
>>
>>
>>
>> done
>>
>>
>>
>> -- What's a "trusted source" in this case?  Is that just a jwks_uri?  If
>> so, maybe s/a trusted source/a reference to a trust source/.  If not, can
>> you please elaborate.
>>
>>
>>
>> Yes, it's just a jwks_uri. I'll change that.
>>
>>
>>
>>
>> A few editorial nits:
>> ** Section 2.2.2.  Typo.  s/sec 4.7/Section 4.7/
>>
>>
>>
>> fixed
>>
>>
>>
>>
>> ** Section 3.1  Cite DER encoding as:
>> [X690] ITU-T, "Information Technology -- ASN.1 encoding rules:
>>   Specification of Basic Encoding Rules (BER), Canonical
>>   Encoding Rules (CER) and Distinguished Encoding Rules
>>   (DER)", ITU-T Recommendation X.690, 2015.
>>
>>
>>
>> will do
>>
>>
>>
>

Re: [OAUTH-WG] Second AD Review: draft-ietf-oauth-mtls

[Brian Campbell]

Thanks Roman, I'll work to incorporate those suggestions into the next
revision before the impending I-D submission cutoff date.

On Mon, Jun 24, 2019 at 2:14 PM Roman Danyliw  wrote:

> Hi Brian!
>
>
>
> My response is inline ...
>
>
>
> *From:* Brian Campbell [mailto:bcampb...@pingidentity.com]
> *Sent:* Monday, June 24, 2019 1:17 PM
> *To:* Roman Danyliw 
> *Cc:* oauth 
> *Subject:* Re: [OAUTH-WG] Second AD Review: draft-ietf-oauth-mtls
>
>
>
> Thanks for the additional review, Roman. I feel lucky, it's not often one
> gets *two* AD reviews :)  Please see below for replies inline with a few
> followup questions.
>
>
>
> [Roman] *chuckle*
>
>
>
> On Sat, Jun 22, 2019 at 12:29 PM Roman Danyliw  wrote:
>
> Hi!
>
> I conducted as second AD review of draft-ietf-oauth-mtls per the AD
> hand-off.  I have the following additional feedback:
>
> ** Per ekr's earlier review at
> https://mozphab-ietf.devsvcdev.mozaws.net/D3657, paraphrasing:
> -- Section 2.1.2, How is these metadata parameters being obtained?
>
>
>
> The authorization server can obtain client metadata via the Dynamic Client
> Registration Protocol [RFC7591], which is referenced in the top of that
> section. Also the metadata defined by RFC7591, and registered extensions to
> it, implies a general data model for clients that is used by most
> authorization server implementations even when the Dynamic Client
> Registration Protocol isn't in play. Such implementations typically have
> some sort of  user interface available for managing client configuration.
>
>
>
> Dose that answer your question? Do you believe more should be said in the
> document to better explain or clarify that?
>
>
>
> [Roman]  It does clear it up.  Thanks.  I think it’s worth a short
> statement about how the AS would get the fields.
>
>
>
>
>
> -- Section 3.2, Figure 3.  In this example, what new information is the
> auth server providing to the relying party here?
>
>
>
> The new info here (and in Section 3.1 too) is the hash of the client
> certificate to which the access token is bound, which is in the "cnf"
> confirmation method at the bottom as the "x5t#S256" member.
>
>
>
> [Roman]  Makes sense.  To make the example clearer, I’d call out this out
> in the prose introducing the example.
>
>
>
>
> ** Section 2.0.  What is the expected behavior if the presented
> certificate doesn't match expected client_id?  How is this signaled?
>
>
>
> With a normal OAuth 2.0 error response using the "invalid_client" error
> code per https://tools.ietf.org/html/rfc6749#section-5.2
>
>
>
> Do you think that needs to be stated more explicitly in this document?
>
>
>
> [Roman] Yes, I’d explicit state it with that citation, especially since
> Section 3 discusses of how errors are returned.
>
>
>
>
> ** Section 2.2.  Per the sentence "As pre-requisite, the client registers
> its X.509 certificate ... or a trusted source for its X.509 certificates
> ... with the authorization server.
> -- Editorial: s/As pre-requisite/As a prerequisite/
>
>
>
> done
>
>
>
> -- What's a "trusted source" in this case?  Is that just a jwks_uri?  If
> so, maybe s/a trusted source/a reference to a trust source/.  If not, can
> you please elaborate.
>
>
>
> Yes, it's just a jwks_uri. I'll change that.
>
>
>
>
> A few editorial nits:
> ** Section 2.2.2.  Typo.  s/sec 4.7/Section 4.7/
>
>
>
> fixed
>
>
>
>
> ** Section 3.1  Cite DER encoding as:
> [X690] ITU-T, "Information Technology -- ASN.1 encoding rules:
>   Specification of Basic Encoding Rules (BER), Canonical
>   Encoding Rules (CER) and Distinguished Encoding Rules
>   (DER)", ITU-T Recommendation X.690, 2015.
>
>
>
> will do
>
>
>
> ** Section 5.  Typo. s/metatdata/metadata/
>
>
>
> yup
>
>
>
>
> ** Section 6.  Typo.  s/The the/The/
>
>
>
> got it
>
>
>
>
> ** Section 7.2. Typo.  s/the the/the/
>
>
>
> done
>
>
>
>
> ** Appendix. Cite the figures numbers (#5 - 7) in the text describing the
> contents of the section.
>
>
>
> will do
>
>
>
>
> The shepherd write-up is in good shape.  Thank you.
>
> Regards,
> Roman
>
>
>
> [Roman] Thanks for all of the above.
>
>
>
> Roman
>
>
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> *CONFIDEN

Re: [OAUTH-WG] Second AD Review: draft-ietf-oauth-mtls

[Brian Campbell]

Thanks for the additional review, Roman. I feel lucky, it's not often one
gets *two* AD reviews :)  Please see below for replies inline with a few
followup questions.



On Sat, Jun 22, 2019 at 12:29 PM Roman Danyliw  wrote:

> Hi!
>
> I conducted as second AD review of draft-ietf-oauth-mtls per the AD
> hand-off.  I have the following additional feedback:
>
> ** Per ekr's earlier review at
> https://mozphab-ietf.devsvcdev.mozaws.net/D3657, paraphrasing:
> -- Section 2.1.2, How is these metadata parameters being obtained?
>

The authorization server can obtain client metadata via the Dynamic Client
Registration Protocol [RFC7591], which is referenced in the top of that
section. Also the metadata defined by RFC7591, and registered extensions to
it, implies a general data model for clients that is used by most
authorization server implementations even when the Dynamic Client
Registration Protocol isn't in play. Such implementations typically have
some sort of  user interface available for managing client configuration.

Dose that answer your question? Do you believe more should be said in the
document to better explain or clarify that?


-- Section 3.2, Figure 3.  In this example, what new information is the
> auth server providing to the relying party here?
>

The new info here (and in Section 3.1 too) is the hash of the client
certificate to which the access token is bound, which is in the "cnf"
confirmation method at the bottom as the "x5t#S256" member.



>
> ** Section 2.0.  What is the expected behavior if the presented
> certificate doesn't match expected client_id?  How is this signaled?
>

With a normal OAuth 2.0 error response using the "invalid_client" error
code per https://tools.ietf.org/html/rfc6749#section-5.2

Do you think that needs to be stated more explicitly in this document?



>
> ** Section 2.2.  Per the sentence "As pre-requisite, the client registers
> its X.509 certificate ... or a trusted source for its X.509 certificates
> ... with the authorization server.
> -- Editorial: s/As pre-requisite/As a prerequisite/
>

done


> -- What's a "trusted source" in this case?  Is that just a jwks_uri?  If
> so, maybe s/a trusted source/a reference to a trust source/.  If not, can
> you please elaborate.
>

Yes, it's just a jwks_uri. I'll change that.


>
> A few editorial nits:
> ** Section 2.2.2.  Typo.  s/sec 4.7/Section 4.7/
>

fixed


>
> ** Section 3.1  Cite DER encoding as:
> [X690] ITU-T, "Information Technology -- ASN.1 encoding rules:
>   Specification of Basic Encoding Rules (BER), Canonical
>   Encoding Rules (CER) and Distinguished Encoding Rules
>   (DER)", ITU-T Recommendation X.690, 2015.
>

will do


> ** Section 5.  Typo. s/metatdata/metadata/
>

yup


> ** Section 6.  Typo.  s/The the/The/
>

got it


>
> ** Section 7.2. Typo.  s/the the/the/
>

done


>
> ** Appendix. Cite the figures numbers (#5 - 7) in the text describing the
> contents of the section.
>

will do


>
> The shepherd write-up is in good shape.  Thank you.
>
> Regards,
> Roman
>
> ___
> 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] Client assertions to endpoints other than the token endpoint

[Brian Campbell]

Yeah, the discussion was/is definitely about "other endpoints at the AS"
like revocation, introspection, device authorization, etc.

On Fri, May 31, 2019 at 12:47 PM George Fletcher  wrote:

> So if by "other endpoints" we mean "other endpoints at the AS" then I
> think issuer makes a lot of sense and could be recommended value.
>
> However, if the client assertion is being sent to an endpoint not managed
> by the AS, then it should use a value that identifies that "audience". In
> this case, something more akin to the "resource identifier" of the endpoint
> is probably best. Abeit, that is still a very fuzzy definition :)
>
> On 5/28/19 11:28 AM, Dave Tonge wrote:
>
> Dear OAuth WG
>
> We have an issue that we are discussing in the OIDF MODRNA work group
> relating to the Client Initiated Back Authentication spec (which is an
> OAuth 2 extension). As the issue affects the wider OAuth ecosystem we
> wanted to post it here and gain feedback from the OAuth Working Group.
>
> Full details of the issue are here:??
> https://bitbucket.org/openid/mobile/issues/155/aud-to-use-in-client_assertion-passed-to??(including
> a helpful context setting by Brian), but the summary is:
>
> *What audience value should a Client use when using a client assertion
> (RFC7521) to authenticate at an endpoint other than the token endpoint?*
>
> The three options we have are:
> 1.??the token endpoint (as RFC7521 says)
> 2. the endpoint the assertion is being sent to (e.g. revocation,
> backchannel)
> 3. the issuer
>
> We are leaning towards requiring the Authorization Server to accept any of
> the above values, but recommending that the Client use the issuer value.
>
> The reasons for this are:
> 1. All of the above values are arguably valid, so in the interest of
> interoperability the AS should accept them all.
> 2. We see no clear security benefit to requiring the audience to be the
> value of the endpoint the assertion is being sent to, and therefore think
> that the issuer value is the one we should recommend that clients use.??
>
> We would be grateful for your feedback on this issue and believe it would
> be in the best interest of the ecosystem for there to be a consistent
> approach to this across OAuth 2 extensions and profiles.
>
> Thanks
>
> Dave Tonge
>
>
> ___
> OAuth mailing listOAuth@ietf.orghttps://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] OAuth WG Sessions in Montreal

[Brian Campbell]

Please allow some time for presentation and discussion of DPoP.

https://tools.ietf.org/html/draft-fett-oauth-dpop-01 is the latest draft
but I hope and expect that there will be an update before Montreal.

On Mon, May 27, 2019 at 3:04 PM Rifaat Shekh-Yusef 
wrote:

> All,
>
> Please, let us know if you have any topics that you would like to discuss
> in Montreal.
>
> Regards,
>  Rifaat & Hannes
>
>
> ___
> 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] MTLS vs. DPOP

[Brian Campbell]

Practically speaking there's the MTLS draft, which has been sent to the
IESG for publication, has commercial and opensource implementations as well
as production deployments, and is referenced by other prospective standards
and profiles. It's not uncommon to receive off list inquires about the
document status from people involved in those things asking when it will be
"finished". Which is to say that there's a good amount of interest from the
community at large in seeing the MTLS document go to RFC. And it's
relatively close to doing so (as these things go anyway). The DPoP
document, on the other hand, is currently an individual draft submission.
And while it has generated some good interest and discussion, it is only an
individual draft submission and carries the same authority as any other
individual draft submission (see
https://tools.ietf.org/html/draft-abr-twitter-reply-00 for example). I
believe that the MTLS draft should continue on the it's course. And am
interested in seeing where we can take the DPoP work and if the WG wants to
take it on.

Your point about the "PR" perspective is taken. And I probably shouldn't
even bring these up but that whole situation is exacerbated by the
expired/dormant WG documents like draft-ietf-oauth-token-binding and
draft-ietf-oauth-signed-http-request. Some organizations out there touting
their support for RFC 7800 as a complete solution in the
pop/sender-constrained space aren't helping matters either. So while I
think I hear what you are saying, I don't personally see much of anything
reasonable or actionable that can done about it.




On Tue, May 7, 2019 at 9:45 AM Vittorio Bertocci  wrote:

> To clarify, I wasn’t suggesting we drop one or the other. Both have their
> merit and use cases, and both should be developed all the way to standard
> IMO. But from some preliminary exploration, it seems unlikely that services
> will adopt both at the same time. From the “pr” perspective, having a clear
> _default_ answer to the question “how do I add sender constraint
> capabilities to my service?” would greatly enhance the chances of getting
> something out in the real world quickly, make it possible to interop and
> iron out wrinkles, etc etc-
> For the general developer populace, at this point “sender constraint”
> remains something vaguely exotic and often decisions made on that (like the
> ones on the implicit deprecation) are poorly received. Even the ones who
> had exposure had been somewhat “burned” by how token binding is going, and
> we are in need for something easy to grok and actionable to rekindle
> interest IMO. The sooner we can get the concept mainstream the better.
>
> On Tue, May 7, 2019 at 07:13 George Fletcher  40aol@dmarc.ietf.org> wrote:
>
>> I don't see them the same at all. With MTLS, the token is bound to the
>> transport layer (and the key used to establish that encrypted connection).
>> With DPOP, the token is bound to the private key known to the client.
>>
>> To compromise an MTLS bound token the attacker has to compromise the
>> private key. To compromise a DPOP bound token, depending on what HTTP
>> request elements are signed, and whether the DPOP is managed as
>> one-time-use etc, there are additional attacks. (Ducks head and waits for
>> all the real security experts to prove me wrong:)
>>
>> The deployment models are also different. With MTLS bound tokens the
>> clients don't really have to know about the binding because it is
>> established at the AS and the deployment of the service manages the cert
>> used for the MTLS connection. This is simpler for client development
>> (provided the environment is already set up for MTLS everywhere).
>>
>> I'd strong encourage us to continue supporting both methods.
>>
>> On 5/7/19 4:25 AM, Hannes Tschofenig wrote:
>>
>> Hi all,
>>
>> ?
>>
>> In the OAuth conference call today Vittorio mentioned that some folks are
>> wondering whether DPOP is essentially a superset of MTLS and whether it
>> makes sense to only proceed with one solution rather potentially two.
>>
>> ?
>>
>> I was wondering whether others in the group have a few about this aspect?
>>
>> ?
>>
>> Ciao
>>
>> Hannes
>>
>> ?
>> 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 listOAuth@ietf.orghttps://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
>

-- 
_CONFIDENTIA

Re: [OAUTH-WG] Token Exchange status and Resource Indicators

[Brian Campbell]

On Tue, May 7, 2019 at 7:03 AM Hannes Tschofenig 
wrote:

>
> The group can define what is in scope of a document and what isn't.
>

Which is what's been done with the document during the course of it's
development and WGLC and subsequent submission to the IESG for publication.

-- 
_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] Token Exchange status and Resource Indicators

[Brian Campbell]

On Fri, May 3, 2019 at 9:39 AM Emond Papegaaij 
wrote:

> [...] we are investigating 'OAuth 2.0
> Token Exchange'. [...] However, I noticed that
> draft 16 has expired on April 22, 2019. Is this specification still active?
>

Yeah, it is. A nontrivial amount of stuff came up in IESG balloting on the
document
https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ballot/
and I have not been able to find the time to make all the necessary
changes. Also, resulting from that IESG balloting there was the need to
request early IANA registrations of some things, which is a whole ordeal
unto itself with timelines I cannot seem to affect much even when I have
the time to try. So it's active but just hung up for a moment at the
moment.


>
> To summarize, I have to following questions:
>  - Is the 'OAuth 2.0 Token Exchange' specification still active?
>

Yes with the caveats mentioned above. I will say that although there's a
lot of work required for the document, none of it is likely to result in
functional changes so I don't anticipate anything breaking at this point.


 - Can 'audience' be added to 'Resource Indicators for OAuth 2.0'?
>

No, that's beyond it's current scope. And it is well past last call in the
WG. But note that a logical identifier can be used as the value of the
resource parameter.


 - Can 'OAuth 2.0 Token Exchange' be updated to build on 'Resource
> Indicators
> for OAuth 2.0' rather than redefining the same parameters?
>

Not really as a matter of timing and process. But the resource parameter
will ultimately be consistent across the two.

-- 
_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] draft-fett-oauth-dpop-01 implementation feedback

[Brian Campbell]

On Thu, May 2, 2019 at 12:33 AM Paul Querna  wrote:

> Overall the spec felt functional, though I think the biggest gaps for
> a deployment are with the Access Token interactions, but this makes
> sense since that seems to be addressed in the future by
> 
>

This DPoP document should aspire to provide sufficient info on access token
interactions so as not to have any dependency on
draft-ietf-oauth-access-token-jwt. And I sorta doubt that PoP style tokens
will be in scope for draft-ietf-oauth-access-token-jwt at all.

Sections 6[a] and 8[b] of DPoP aim to define access token usage. Is there
specific content that you feel is missing in the draft?

[a] https://tools.ietf.org/html/draft-fett-oauth-dpop-01#section-6
[b] https://tools.ietf.org/html/draft-fett-oauth-dpop-01#section-8



> Is there a use case for this being present in the DPoP-Proof JWT?  As
> I've implemented DPoP, I didn't see how it was helpful to be sent as a
> `cnf` claim of the Proof?
>

As David alluded to in his reply yesterday, this is an area that is likely
to see some changes in the next revision of the draft - like doing away
with the distinction between binding and proof, moving the proof key out of
the JWT and less inappropriate use of the `cnf` claim.

But in the -01 draft the key is included with the access token via the
`cnf` claim and you're right that it's not particularly helpful to have it
also sent with the Proof.



> Request Headers vs Parameters
> > 5.  Token Request (Binding Tokens to a Public Key)
>
> Placing the DPoP Binding JWT in the HTTP Header `DPoP-Binding` is
> different than most other OAuth extensions that I am familiar with.
> It is easy in the Go OAuth2 library to add URL / /body params to the
> `/token` endpoint, but it is impossible to add an HTTP Header.  Is
> there a reason that the binding can't be sent as an OAuth Parameter in
> the token request body?
>

Also as David alluded to in his reply yesterday, there's a goal to have the
proof mechanism be the same for accessing the token endpoint as when
accessing resources. And using application/x-www-form-urlencoded parameters
for resource access is problematic for a litany of reasons.



HTTP Request signing may be a quagmire that this spec wishes to avoid,
>

Very much so, yes.


[snip] I'm not sure where the spec-author team wants to take this area, but
> am interested in providing feedback.
>

Somehow cleanly allowing for it by extension would be nice from the
perspective of this document. But full treatment of HTTP signing is
explicitly a non-goal of the DPoP draft with the intent that it have only a
minimal set of stuff that's signed so as to facilitate the
proof-of-possession.


JWT as AT
> >  7.  IANA Considerations
> >
> >[[TODO: MIME type registration for at+jwt ]]
>
> Assume this will eventually be done via
> 
>

That's already where it is, no?



Thank you for the work so far, and I'm happy to provide further
> feedback as the spec evolves.
>

Thanks Paul, it's just a -01 version of an individual draft at this point
(with all the authority thereby bestowed on it
) but your
participation would certainly be appreciated as the spec evolves and if
it's something the working group decides to pick up as a working group
item.

-- 
_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] Transaction Authorization with OAuth

[Brian Campbell]

On Tue, Apr 30, 2019 at 5:03 AM Torsten Lodderstedt 
wrote:

>
>
> > On 26. Apr 2019, at 19:57, Brian Campbell 
> wrote:
> >
> > One thing that I think is missing from the article in the discussion of
> pros and cons is that in many cases a large or even voluminous request can
> be sent via auto submitting form post (like
> https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html but
> the other way around from client to AS with the auth request), which
> doesn't then run into the same URI size problem.
>
> Thanks for pointing this out! Is the response mode often used in the wild
> for OAuth?
>

It's not really a "response mode" for sending the request but the idea is
basically the same just going the other direction. The possibility is
implied by the text near the end of
https://tools.ietf.org/html/rfc6749?#section-3.1 that says,

  'The authorization server MUST support the use of the HTTP "GET"
   method [RFC2616] for the authorization endpoint and MAY support the
   use of the "POST" method as well.'

I know our AS will happily accept POST at the authorization endpoint and I
suspect many others will too. But I don't have any data how often it is
used in the wild for 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] How to deal with multi-valued request parameters in a JAR (draft-ietf-oauth-jwsreq-17)?

[Brian Campbell]

Errata 5708 has been reported attempting to clarify the situation.

https://www.rfc-editor.org/errata/eid5708

On Mon, Apr 22, 2019 at 9:53 AM Thomas Broyer  wrote:

> And the root issue is that it *is* subject to interpretation.
>
> Parameters sent without a value MUST be treated as if they were
>omitted from the request.  The authorization server MUST ignore
>unrecognized request parameters.  Request and response parameters
>MUST NOT be included more than once.
>
>
> The first sentence clearly applies to all parameters, whether recognized or 
> not.
>
> It's unfortunately not clear to what the third applies, but BECAUSE it can be 
> understood as applying to unrecognized parameters as well, I think it SHOULD 
> be interpreted that way (until an errata clarifies the situation)
>
>
> Le lun. 22 avr. 2019 17:39, Brian Campbell  a
> écrit :
>
>> My interpretation of RFC6749's “Request and response parameters MUST NOT
>> be included more than once" is that it is applicable only to the parameters
>> defined therein. Which (conveniently but defensibly) allows for extensions
>> like resource indicators and token exchange to have multiple instances of a
>> parameter value without having to invent some new scheme to encode or
>> delimit multiple values.
>>
>> On Mon, Apr 22, 2019 at 7:52 AM Thomas Broyer  wrote:
>>
>>> RFC6749 makes it clear that “Request and response parameters MUST NOT be
>>> included more than once.”
>>> So:
>>>  * multi-valued request params shouldn't exist ("scope" is a single
>>> string value with a specific format, as a space-separated list of scopes)
>>>  * resource indicators draft violates RFC6749 by explicitly allowing
>>> multiple "resource" params; and RFC6749-compliant server is free to reject
>>> such a request with an invalid_request error, meaning that resource
>>> indicators breaks interoperability (clients can only send multi resource
>>> params to servers they know won't reject them with invalid_request as
>>> they're allowed to by RC6749).
>>> One could interpret that stance in RFC6749 as applying only to those
>>> params defined in this spec, but it's not explicitly said, so it could be
>>> interpreted as applying to any parameter, including extensions (like
>>> resource indicators) or unrecognized (and therefore ignored) parameters...
>>>
>>> On Mon, Apr 22, 2019 at 10:15 AM Vladimir Dzhuvinov <
>>> vladi...@connect2id.com> wrote:
>>>
>>>> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-17#section-4
>>>>
>>>> How should multi-valued request params be expressed in the JWT claims
>>>> set? As values in a JSON array?
>>>>
>>>>  {
>>>>   "iss": "s6BhdRkqt3",
>>>>   "aud": "https://server.example.com"; <https://server.example.com>,
>>>>   "response_type": "code id_token",
>>>>   "client_id": "s6BhdRkqt3",
>>>>   "redirect_uri": "https://client.example.org/cb"; 
>>>> <https://client.example.org/cb>,
>>>>   "scope": "openid",
>>>>   "state": "af0ifjsldkj",
>>>>   "some-query-param": [ "val-1", "val-2" ]
>>>>  }
>>>>
>>>> Apart from custom params, the resource indicators spec also suggests
>>>> that such situations can occur:
>>>>
>>>>
>>>> https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-02#section-2
>>>>
>>>> Thanks,
>>>>
>>>> Vladimir
>>>> ___
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>
>>>
>>> --
>>> Thomas Broyer
>>> /tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>
>>> ___
>>> 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.*
>
>

-- 
_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] Transaction Authorization with OAuth

[Brian Campbell]

One thing that I think is missing from the article in the discussion of
pros and cons is that in many cases a large or even voluminous request can
be sent via auto submitting form post (like
https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html but the
other way around from client to AS with the auth request), which doesn't
then run into the same URI size problem.

>From a prospective standardization standpoint, there are really two
distinct concepts in the article. One is the "Pushed Request Object" and
the other the "Structured Scope". They are certainly complementary things
but each could also be useful and used independently of one another. So I'd
argue that they should be developed independently too.



On Sat, Apr 20, 2019 at 12:21 PM Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:

> Hi all,
>
> I just published an article about the subject at:
> https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-2326e2038948
>
>
> I look forward to getting your feedback.
>
> kind regards,
> Torsten.
> ___
> 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] How to deal with multi-valued request parameters in a JAR (draft-ietf-oauth-jwsreq-17)?

[Brian Campbell]

My interpretation of RFC6749's “Request and response parameters MUST NOT be
included more than once" is that it is applicable only to the parameters
defined therein. Which (conveniently but defensibly) allows for extensions
like resource indicators and token exchange to have multiple instances of a
parameter value without having to invent some new scheme to encode or
delimit multiple values.

On Mon, Apr 22, 2019 at 7:52 AM Thomas Broyer  wrote:

> RFC6749 makes it clear that “Request and response parameters MUST NOT be
> included more than once.”
> So:
>  * multi-valued request params shouldn't exist ("scope" is a single string
> value with a specific format, as a space-separated list of scopes)
>  * resource indicators draft violates RFC6749 by explicitly allowing
> multiple "resource" params; and RFC6749-compliant server is free to reject
> such a request with an invalid_request error, meaning that resource
> indicators breaks interoperability (clients can only send multi resource
> params to servers they know won't reject them with invalid_request as
> they're allowed to by RC6749).
> One could interpret that stance in RFC6749 as applying only to those
> params defined in this spec, but it's not explicitly said, so it could be
> interpreted as applying to any parameter, including extensions (like
> resource indicators) or unrecognized (and therefore ignored) parameters..
>
> On Mon, Apr 22, 2019 at 10:15 AM Vladimir Dzhuvinov <
> vladi...@connect2id.com> wrote:
>
>> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-17#section-4
>>
>> How should multi-valued request params be expressed in the JWT claims
>> set? As values in a JSON array?
>>
>>  {
>>   "iss": "s6BhdRkqt3",
>>   "aud": "https://server.example.com"; ,
>>   "response_type": "code id_token",
>>   "client_id": "s6BhdRkqt3",
>>   "redirect_uri": "https://client.example.org/cb"; 
>> ,
>>   "scope": "openid",
>>   "state": "af0ifjsldkj",
>>   "some-query-param": [ "val-1", "val-2" ]
>>  }
>>
>> Apart from custom params, the resource indicators spec also suggests that
>> such situations can occur:
>>
>>
>> https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-02#section-2
>>
>> Thanks,
>>
>> Vladimir
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
>
> --
> Thomas Broyer
> /tɔ.ma.bʁwa.je/ 
> ___
> 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] How to deal with multi-valued request parameters in a JAR (draft-ietf-oauth-jwsreq-17)?

[Brian Campbell]

FWIW, the second paragraph of resource indicators, section 2.1

says to use a JSON array via the following text:

   For authorization requests sent as a JWTs, such as when using JWT
   Secured Authorization Request [I-D.ietf-oauth-jwsreq
],
a single
   "resource" parameter value is represented as a JSON string while
   multiple values are represented as an array of strings.


On Mon, Apr 22, 2019 at 2:15 AM Vladimir Dzhuvinov 
wrote:

> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-17#section-4
>
> How should multi-valued request params be expressed in the JWT claims set?
> As values in a JSON array?
>
>  {
>   "iss": "s6BhdRkqt3",
>   "aud": "https://server.example.com"; ,
>   "response_type": "code id_token",
>   "client_id": "s6BhdRkqt3",
>   "redirect_uri": "https://client.example.org/cb"; 
> ,
>   "scope": "openid",
>   "state": "af0ifjsldkj",
>   "some-query-param": [ "val-1", "val-2" ]
>  }
>
> Apart from custom params, the resource indicators spec also suggests that
> such situations can occur:
>
>
> https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-02#section-2
>
> Thanks,
>
> Vladimir
> ___
> 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-WG] draft-ietf-oauth-mtls-14

[Brian Campbell]

Draft -14 of "OAuth 2.0 Mutual TLS Client Authentication and
Certificate-Bound Access Tokens" has been published. The changes in -14
(listed below) are editorial only and aim to provide some additional
clarity around some recent small points of confusion and discussion.

draft-ietf-oauth-mtls-14
   o  Editorial clarifications around there being only a single subject
  registered/configured per client for the tls_client_auth method.
   o  Add a brief explanation about how, with tls_client_auth and
  self_signed_tls_client_auth, refresh tokens are certificate-bound
  indirectly via the client authentication.
   o  Add mention of refresh tokens in the abstract.

-- Forwarded message -
From: 
Date: Thu, Apr 11, 2019 at 2:21 PM
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-14.txt
To: 
Cc: 



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

Title   : OAuth 2.0 Mutual TLS Client Authentication and
Certificate-Bound Access Tokens
Authors     : Brian Campbell
  John Bradley
  Nat Sakimura
  Torsten Lodderstedt
Filename: draft-ietf-oauth-mtls-14.txt
Pages   : 30
Date: 2019-04-11

Abstract:
   This document describes OAuth client authentication and certificate-
   bound access and refresh tokens using mutual Transport Layer Security
   (TLS) authentication with X.509 certificates.  OAuth clients are
   provided a mechanism for authentication to the authorization server
   using mutual TLS, based on either self-signed certificates or public
   key infrastructure (PKI).  OAuth authorization servers are provided a
   mechanism for binding access tokens to a client's mutual TLS
   certificate, and OAuth protected resources are provided a method for
   ensuring that such an access token presented to it was issued to the
   client presenting the token.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-mtls-14
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-14

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-mtls-14


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

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

___
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] MTLS and SAN

[Brian Campbell]

Thanks Justin.

On Mon, Apr 8, 2019 at 5:49 PM Justin Richer  wrote:

> Thanks for the clarifications everyone. Since I didn’t catch the
> one-and-only-one sentiment when reading the updates, I would recommend
> altering the text as follows in §2.1:
>
>The PKI (public key infrastructure) method of mutual TLS OAuth client
>authentication adheres to the way in which X.509 certificates are
>traditionally used for authentication.  It relies on a *single *subject
>distinguished name (DN) or a *single* subject alternative name (SAN) 
> ** to authenticate the client. *The client’s certificate chain 
> is validated [RFC5280] and only one name value of any type is used for each 
> client.*
>The TLS handshake is utilized to validate the client's possession of
>the private key corresponding to the public key in the certificate
>and to validate the corresponding certificate chain.  The client is
>successfully authenticated if the subject information in the
>certificate matches the *single *expected subject configured or registered 
> for
>that particular client (note that a predictable treatment of DN
>values, such as the distinguishedNameMatch rule from [RFC4517 
> <https://tools.ietf.org/html/rfc4517>], is
>needed in comparing the certificate's subject DN to the client's
>registered DN).  Revocation checking is possible with the PKI method
>but if and how to check a certificate's revocation status is a
>deployment decision at the discretion of the authorization server.
>Clients can rotate their X.509 certificates without the need to
>modify the respective authentication data at the authorization server
>by obtaining a new certificate with the same subject from a trusted
>certificate authority (CA).
>
>
>
> I think the listing of methods is clear enough as it is — but my problem
> was that I read the above paragraph, then jumped right into the list below
> for the exact fields without reading its own introductory paragraph as well.
>
> — Justin
>
> On Apr 8, 2019, at 1:54 PM, Brian Campbell 
> wrote:
>
> Yes, the intent is that the client be configured (dynamically or
> statically or however that comes to be) with one and only one expected
> subject, which also includes the location in the certificate that subject
> will be. And that is checked against at authentication time.
>
> As the writer of the questionable text in question, it does seem pretty
> clear to me as it is now. But as the writer, I'm also probably not well
> positioned to see how it could be made more clearer. So if either of you
> gentlemen have concrete text suggestions to help there, please send em for
> consideration.
>
> On Thu, Apr 4, 2019 at 2:55 PM Filip Skokan  wrote:
>
>> Yes.
>>
>> S pozdravem,
>> *Filip Skokan*
>>
>>
>> On Thu, 4 Apr 2019 at 22:36, Justin Richer  wrote:
>>
>>> Thank you, I did miss that text. This should be called out more
>>> explicitly in §2.1, perhaps by specifying that it is only one field. This
>>> still doesn’t set precedence, but it implies that it’s an error for a
>>> client to have more than one field set of the available options. Is that
>>> your read on this as well?
>>>
>>> — Justin
>>>
>>> On Apr 4, 2019, at 4:23 PM, Filip Skokan  wrote:
>>>
>>> Justin, I had the exact same question off list and believe draft 13
>>> clarified this.
>>>
>>> https://tools.ietf.org/html/draft-ietf-oauth-mtls-13#section-2.1.2
>>>
>>> A client using the "tls_client_auth" authentication method MUST use
>>> exactly one of the below metadata parameters to indicate the certificate
>>> subject value that the authorization server is to expect when
>>> authenticating the respective client.
>>>
>>> Then it lists the different dn/san properties.
>>>
>>> S pozdravem,
>>> *Filip Skokan*
>>>
>>>
>>> On Thu, 4 Apr 2019 at 22:20, Justin Richer  wrote:
>>>
>>>> We’ve just started implementation of SAN-based certificate
>>>> authentication, based on the changes in version -13 of the draft. I believe
>>>> this addition is a bit unclear, due to it being added so late in the
>>>> document process.
>>>>
>>>> My question is how does an AS determine whether to DN or SAN for
>>>> certificate checking? Corollary, are these mutually exclusive or can they
>>>> be used together? Currently, the specification text lists DN and SAN as an
>>>> “or” with no indication whether this is 

Re: [OAUTH-WG] draft-fett-oauth-dpop-00

[Brian Campbell]

The thought/intent is that it's really about proof-of-possession rather
than protecting the request. So the signature is over a minimal set of
information.

On Mon, Apr 8, 2019 at 5:41 PM Justin Richer  wrote:

> Corollary to this, are there thoughts of header protection under this
> method, and the associated issue of header modification?
>
> — Justin
>
> On Apr 8, 2019, at 7:23 PM, Phil Hunt  wrote:
>
> Question. One of the issues that Justin Richer’s signing draft tried to
> address was url modification by tls terminators/load balencers/proxies/api
> gateways etc.
>
> How do you see this issue in dpop? Is it a problem?
>
> Phil
>
> On Apr 3, 2019, at 9:01 AM, George Fletcher <
> gffletch=40aol@dmarc.ietf.org> wrote:
>
> Perfect! Thank you! A couple comments on version 01...
>
>POST /token HTTP/1.1
>Host: server.example.com
>Content-Type: application/x-www-form-urlencoded;charset=UTF-8
>DPoP-Binding: eyJhbGciOiJSU0ExXzUi ...
>
>grant_type=authorization_code
>&code=SplxlOBeZQQYbYS6WxSbIA
>&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
>(remainder of JWK omitted for brevity)
>
>
> I believe the "(remainder of JWK..." should be moved to the DPoP-Binding
> header...
>
> Also, there is no discussion of the DPoP-Binding header outside of the
> token request, but I suspect that is the desired way to communicate the
> DPoP-Proof to the RS.
>
> Possibly an example in the session for presenting the token to the RS
> would help.
>
> Thanks,
> George
>
> On 4/3/19 11:39 AM, Daniel Fett wrote:
>
> This is fixed in -01:
>
> https://tools.ietf.org/html/draft-fett-oauth-dpop-01
> 
>
> -Daniel
>
> Am 03.04.19 um 17:28 schrieb George Fletcher:
>
> A quick question regarding...
>
>o  "http_uri": The HTTP URI used for the request, without query and
>   fragment parts (REQUIRED).
>
>
> Is 'without' supposed to be 'with' ? The example shows the http_uri *with*
> the query parameters :)
>
> On 3/28/19 6:17 AM, Daniel Fett wrote:
>
> Hi all,
>
> I published the first version of the DPoP draft at
> https://tools.ietf.org/html/draft-fett-oauth-dpop-00
> 
>
> Abstract
>
>This document defines a sender-constraint mechanism for OAuth 2.0
>access tokens and refresh tokens utilizing an application-level
>proof-of-possession mechanism based on public/private key pairs.
>
>
> Thanks for the feedback I received so far from John, Mike, Torsten, and
> others during today's session or before!
>
> If you find any errors I would welcome if you open an issue in the GitHub
> repository at https://github.com/webhamster/draft-dpop
> 
>
> - Daniel
>
> ___
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth 
> 
>
>
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=eQpusEFY7fROXNfEJmh0QzkejgdgaVnILpbm2q8x9II&s=8LDvfTYESi1fDeRK7mQrHFeo9okoJ4NTZU4OHyeRJWk&e=
>
> ___
> 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._

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

[Brian Campbell]

ormation, and
> implementations WILL find a way to get the info they are interested into.
> To me that's all the more reasons to provide guidance on how to do so being
> aware of pitfalls and with whatever protections we can put in place, as
> opposed to leave developers to their own device.
>
> On Thu, Apr 4, 2019 at 9:32 AM Brian Campbell  40pingidentity@dmarc.ietf.org> wrote:
>
>> A few remarks/responses inline below this time...
>>
>> On Wed, Apr 3, 2019 at 1:38 PM Vittorio Bertocci > 40auth0@dmarc.ietf.org> wrote:
>>
>>> Thanks guys for the comment, sorry for the delay in addressing them.
>>> I am not married to the claim types used in here, so if you think that
>>> reusing the ones in the id_token can cause confusion we should expand on
>>> the specific ways in which you think might go south.
>>>
>>
>> My concern isn't with reusing the names/types of the claims per se.  But
>> more generally that codifying the use of certain authentication-centric
>> claims in the context of an access token furthers the potential confusion
>> around authentication vs. authorization that has been a nagging problem for
>> OAuth (i.e. the https://oauth.net/articles/authentication/ article).
>>
>>
>> However I think it's important that the information on say, whether the
>>> current token was obtained using MFA or a specific authentication factor is
>>> something that API developers can legitimately latch to when doing
>>> authorization decisions. From the perspective of a developer modeling a
>>> solution, whether functionality is delivered as a route in a postback based
>>> web app (hence receiving an id_token or derived) or as an API consumed by a
>>> native app, the business requirement gating access to that functionality
>>> doesn't change. If the admin managing that resource establishes that access
>>> should be performed only via MFA, the developer should be equipped to
>>> enforce that regardless of the stack used to expose functionality (web app,
>>> API).
>>> Although it is true that triggering the desired behavior might be
>>> achieved by the resource setting and contract with the AS, along the lines
>>> of what David said, it's actually not uncommon for those policies to be
>>> assigned on the resource AFTER the current session was established and/or
>>> the corresponding AT was obtained and cached. Furthermore, the requirement
>>> might be more granular than an AS policy can tolerate (an API might
>>> requires MFA only for certain routes, hence hard to express in a static
>>> policy) and triggered in form of challenges. So the situation in which you
>>> have an AT with the right issuer, audience, etc but was obtained with a
>>> policy now obsolete/unacceptable to the RP is strong. Requesting to support
>>> revocation just for this seems overkill, especially given that the scenario
>>> in which the same logical app is exposed as both web app and native
>>> client+API, the code consuming those claims is already in place. It just
>>> makes intuitive sense for developers.
>>> In summary, one can take steps to push as much of the MFA requirements
>>> to the AS settings for a particular request, but ultimately the desire of
>>> the API developer to enforce that it actually happened is a requirement I
>>> encountered often in practice. Anything providing extra context to refine
>>> decisions about it (like auth_time, which might inform decisions about
>>> whether to accept an MFA check occurred N minutes ago or refuse access)..
>>>
>>
>> I understand what you are saying but but personally do not find it
>> sufficiently compelling.  But that's just my opinion and not a hill I want
>> to die on (at the present time anyway)..
>>
>>
>>
>>> I thought that reusing the existing names for the same concepts just
>>> made sense (dev existing skills, existing codebases, etc etc) and
>>> especially in the case in which the values are exactly the same, and the
>>> idea seemed to receive good support during OSW.
>>>
>>
>> Our recollection of OSW differs somewhat. As I recall there was support
>> for pointing to identity claims from OIDC for additional end-user info. But
>> there was some grumbling (from John and myself at least) at first mention
>> of acr/amr and auth_time. By the time it came up again near the end of the
>> last unconference session, I wasn't wanting to prolong things because I was
>> kinda worn out for the day and w

Re: [OAUTH-WG] MTLS and SAN

[Brian Campbell]

Yes, the intent is that the client be configured (dynamically or statically
or however that comes to be) with one and only one expected subject, which
also includes the location in the certificate that subject will be. And
that is checked against at authentication time.

As the writer of the questionable text in question, it does seem pretty
clear to me as it is now. But as the writer, I'm also probably not well
positioned to see how it could be made more clearer. So if either of you
gentlemen have concrete text suggestions to help there, please send em for
consideration.

On Thu, Apr 4, 2019 at 2:55 PM Filip Skokan  wrote:

> Yes.
>
> S pozdravem,
> *Filip Skokan*
>
>
> On Thu, 4 Apr 2019 at 22:36, Justin Richer  wrote:
>
>> Thank you, I did miss that text. This should be called out more
>> explicitly in §2.1, perhaps by specifying that it is only one field.. This
>> still doesn’t set precedence, but it implies that it’s an error for a
>> client to have more than one field set of the available options. Is that
>> your read on this as well?
>>
>> — Justin
>>
>> On Apr 4, 2019, at 4:23 PM, Filip Skokan  wrote:
>>
>> Justin, I had the exact same question off list and believe draft 13
>> clarified this.
>>
>> https://tools.ietf.org/html/draft-ietf-oauth-mtls-13#section-2.1.2
>>
>> A client using the "tls_client_auth" authentication method MUST use
>> exactly one of the below metadata parameters to indicate the certificate
>> subject value that the authorization server is to expect when
>> authenticating the respective client.
>>
>> Then it lists the different dn/san properties.
>>
>> S pozdravem,
>> *Filip Skokan*
>>
>>
>> On Thu, 4 Apr 2019 at 22:20, Justin Richer  wrote:
>>
>>> We’ve just started implementation of SAN-based certificate
>>> authentication, based on the changes in version -13 of the draft. I believe
>>> this addition is a bit unclear, due to it being added so late in the
>>> document process.
>>>
>>> My question is how does an AS determine whether to DN or SAN for
>>> certificate checking? Corollary, are these mutually exclusive or can they
>>> be used together? Currently, the specification text lists DN and SAN as an
>>> “or” with no indication whether this is an inclusive or exclusive “or”, and
>>> what to do when there’s overlap.
>>>
>>> This has implications both for the implementation of the server
>>> processing the request as well as the client metadata model, since the
>>> client fields are all in parallel to each other. I can see a few ways of
>>> handling this.
>>>
>>>
>>> 1) One of the fields takes precedence over the other. Say for example
>>> you choose the DN field: if it’s set, then you do DN matching and ignore
>>> the SAN fields entirely, both in the cert and in the client’s registration.
>>> Inverse is true if you choose the SAN fields over the DN but the principle
>>> is the same. We should be explicit if there’s an intended precedence
>>> between these two, and even more explicit if the DN and SAN are at equal
>>> level and the AS gets to choose. We also need to be clear if it’s an error
>>> condition if both are set simultaneously, like the way that jwks and
>>> jwks_uri are mutually exclusive.
>>> 2) You set an explicit switch in your client model that says whether to
>>> use the DN or the SAN fields in comparison, and your code branches based on
>>> that to either DN or SAN processing. This could also be added as an
>>> explicit client metadata field, or it could be an internal detail. If an
>>> internal detail, we should be explicit about there not being a predefined
>>> precedence between the fields.
>>> 3) If it’s allowable to use them together, you match everything that’s
>>> set in the client, and at least one field MUST be set.
>>>
>>>
>>> What’s the intended behavior for implementers, and should we be more
>>> explicit about this? We are starting our implementation with (1) pending
>>> the outcome of this thread, and I’d be curious to know how others are
>>> implementing this in their systems.
>>>
>>> Thanks,
>>> — Justin
>>>
>>> ___
>>> 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] Early IANA registration for Token Exchange Draft

[Brian Campbell]

The request originated from Ben Kaduk's Discuss ballot on the draft and
suggestion that the URI values be registered.

Some of the relevant messages in the thread:
https://mailarchive.ietf.org/arch/msg/oauth/QiA5PDBsKlApNZIRy3QOttd-JDM
https://mailarchive.ietf.org/arch/msg/oauth/E2eOLE576c_Zw6MK0ysouEbmrrw
https://mailarchive.ietf.org/arch/msg/oauth/GKh_vAtvD3bAcuBJ7OXxquVcrmM
https://mailarchive.ietf.org/arch/msg/oauth/f4tBwgOO2NlhOJobUKNdw2wCPAU

On Mon, Apr 1, 2019 at 5:33 AM Hannes Tschofenig 
wrote:

> Hi all
>
>
>
> The authors of the token exchange draft asked IANA for an early
> registration of URIs and parameters, token types, claims, etc.
>
>
>
> IANA asked me for review and I unfortunately do not know (or remember) why
> this early registration is needed.
>
>
>
> Any reason to do this early registration?
>
>
>
> Ciao
>
> Hannes
>
>
> 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
>

-- 
_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] draft-bertocci-oauth-access-token-jwt-00

[Brian Campbell]

A few remarks/responses inline below this time...

On Wed, Apr 3, 2019 at 1:38 PM Vittorio Bertocci  wrote:

> Thanks guys for the comment, sorry for the delay in addressing them.
> I am not married to the claim types used in here, so if you think that
> reusing the ones in the id_token can cause confusion we should expand on
> the specific ways in which you think might go south.
>

My concern isn't with reusing the names/types of the claims per se.  But
more generally that codifying the use of certain authentication-centric
claims in the context of an access token furthers the potential confusion
around authentication vs. authorization that has been a nagging problem for
OAuth (i.e. the https://oauth.net/articles/authentication/ article).


However I think it's important that the information on say, whether the
> current token was obtained using MFA or a specific authentication factor is
> something that API developers can legitimately latch to when doing
> authorization decisions. From the perspective of a developer modeling a
> solution, whether functionality is delivered as a route in a postback based
> web app (hence receiving an id_token or derived) or as an API consumed by a
> native app, the business requirement gating access to that functionality
> doesn't change. If the admin managing that resource establishes that access
> should be performed only via MFA, the developer should be equipped to
> enforce that regardless of the stack used to expose functionality (web app,
> API).
> Although it is true that triggering the desired behavior might be achieved
> by the resource setting and contract with the AS, along the lines of what
> David said, it's actually not uncommon for those policies to be assigned on
> the resource AFTER the current session was established and/or the
> corresponding AT was obtained and cached. Furthermore, the requirement
> might be more granular than an AS policy can tolerate (an API might
> requires MFA only for certain routes, hence hard to express in a static
> policy) and triggered in form of challenges. So the situation in which you
> have an AT with the right issuer, audience, etc but was obtained with a
> policy now obsolete/unacceptable to the RP is strong. Requesting to support
> revocation just for this seems overkill, especially given that the scenario
> in which the same logical app is exposed as both web app and native
> client+API, the code consuming those claims is already in place. It just
> makes intuitive sense for developers.
> In summary, one can take steps to push as much of the MFA requirements to
> the AS settings for a particular request, but ultimately the desire of the
> API developer to enforce that it actually happened is a requirement I
> encountered often in practice. Anything providing extra context to refine
> decisions about it (like auth_time, which might inform decisions about
> whether to accept an MFA check occurred N minutes ago or refuse access).
>

I understand what you are saying but but personally do not find it
sufficiently compelling.  But that's just my opinion and not a hill I want
to die on (at the present time anyway).



> I thought that reusing the existing names for the same concepts just made
> sense (dev existing skills, existing codebases, etc etc) and especially in
> the case in which the values are exactly the same, and the idea seemed to
> receive good support during OSW.
>

Our recollection of OSW differs somewhat. As I recall there was support for
pointing to identity claims from OIDC for additional end-user info. But
there was some grumbling (from John and myself at least) at first mention
of acr/amr and auth_time. By the time it came up again near the end of the
last unconference session, I wasn't wanting to prolong things because I was
kinda worn out for the day and wanting to get to Frankfurt that evening
before sunset ('cause I like to do stuff like this:
https://flic.kr/p/2fiAaPe :) ).



> But I am completely open to change it of course, especially for cases like
> the one identified by George.
>

FWIW, to me, George's suggestion "assume[ing] that the auth_time value
should be updated to the latest time at which the user authenticated"
though some unspecified and in many cases non-existent link between the AT
and a current user session at the AS is an example of how
authentication-centric claims in an access token can be confusing.




> WDYT?
>
> On Wed, Apr 3, 2019 at 10:24 AM Brian Campbell  40pingidentity@dmarc.ietf.org> wrote:
>
>> +1 to David's question here. I'd like to see justifying use cases (beyond
>> just the fact that some people are already doing it) for auth_time, acr,
>> and amr to be available in OAuth JWT access tokens. Those claims are
>> defined for, and in

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

[Brian Campbell]

I'm not sure I understand what you mean but this document would reference
the RFC 7519 claims and, if needed, futher profile their usage for access
tokens.

On Thu, Apr 4, 2019 at 9:39 AM Hans Zandbelt 
wrote:

> agreed but it (i.e. "sub") also brings us back to where we started
>
> Hans.
>
> On Thu, Apr 4, 2019 at 5:27 PM Brian Campbell  40pingidentity@dmarc.ietf.org> wrote:
>
>> The same is true for most of the other main claims too - iss, exp, aud,
>> sub, iat, etc.. They are defined in RFC 7519 not OIDC.
>>
>> On Thu, Apr 4, 2019 at 9:21 AM Brian Campbell 
>> wrote:
>>
>>> Yeah, OpenID.Core isn't the right reference for `aud`.
>>> https://tools.ietf.org/html/rfc7519#section-4.1.3 is the definition of
>>> `aud` which should be the reference and this document can provide
>>> additional specifics for the given application.
>>>
>>> On Thu, Apr 4, 2019 at 8:07 AM George Fletcher >> 40aol@dmarc.ietf.org> wrote:
>>>
>>>> Another comment...
>>>>
>>>>aud  REQUIRED - as defined in section 2 of [OpenID.Core 
>>>> <https://tools.ietf.org/html/draft-bertocci-oauth-access-token-jwt-00#ref-OpenID.Core>].
>>>>   See
>>>>   Section 3 
>>>> <https://tools.ietf.org/html/draft-bertocci-oauth-access-token-jwt-00#section-3>
>>>>  for indications on how an authorization server should
>>>>   determine the value of aud depending on the request.  [Note: some
>>>>   vendors seem to rely on resource aliases.  If we believe this to
>>>>   be a valuable feature, here's some proposed language: The aud
>>>>   claim MAY include a list of individual resource indicators if they
>>>>   are all aliases referring to the same requested resource known by
>>>>   the authorization server. ]
>>>>
>>>>
>>>>
>>>> I don't think OpenID.Core Section 3 is the correct reference for
>>>> determining the 'aud' value. The issue here is that the 'aud' of the
>>>> id_token is the recipient of the id_token (i.e. the client). However, for
>>>> access_tokens the 'aud' value should be the resource service that will
>>>> receive the access_token. There is no existing guidance for this and we
>>>> should provide such guidance as this is "kind of new" for OAuth2 (from an
>>>> explicit specification perspective).
>>>>
>>>> Also, there is the concept of 'azp' from the id_token which amounts to
>>>> "who's allowed to present this token" which might be interesting from the
>>>> case where one entity obtains the token, and gives it to another entity to
>>>> present. Not sure if we want to include this concept or not.
>>>>
>>>> Finally, I think we may need some best practice around how the concept
>>>> of audience and resource should be managed. For instance...
>>>>
>>>>If the request does not include a resource parameter, the
>>>>authorization server MUST use in the aud claim a default resource
>>>>indicator.  If a scope parameter is present in the request, the
>>>>authorization server SHOULD use it to infer the value of the default
>>>>resource indicator to be used in the aud claim.
>>>>
>>>>
>>>> I think for most implementations this would amount to... define an
>>>> audience that covers all the resource services where the access token can
>>>> be returned and set that as the audience (e.g. urn:x-mydomain:apis). Which
>>>> is perfectly legal but maybe not in the spirit of the spec:) I am receiving
>>>> feedback from developers that binding access tokens narrowly to the
>>>> resource where they will be presented is concerning from a chattiness
>>>> perspective (latency issues) and general load on the deployed AS
>>>> infrastructure.
>>>>
>>>> On 3/24/19 7:29 PM, Vittorio Bertocci wrote:
>>>>
>>>> Dear all,
>>>> I just submitted a draft describing a JWT profile for OAuth 2.0 access
>>>> tokens. You can find it in
>>>> https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/
>>>> .
>>>> I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting
>>>> remotely). I look forward for your comments!
>>>>
>>>> Here's just a bit of backs

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

[Brian Campbell]

The same is true for most of the other main claims too - iss, exp, aud,
sub, iat, etc.. They are defined in RFC 7519 not OIDC.

On Thu, Apr 4, 2019 at 9:21 AM Brian Campbell 
wrote:

> Yeah, OpenID.Core isn't the right reference for `aud`.
> https://tools.ietf.org/html/rfc7519#section-4.1.3 is the definition of
> `aud` which should be the reference and this document can provide
> additional specifics for the given application.
>
> On Thu, Apr 4, 2019 at 8:07 AM George Fletcher  40aol@dmarc.ietf.org> wrote:
>
>> Another comment...
>>
>>aud  REQUIRED - as defined in section 2 of [OpenID.Core 
>> <https://tools.ietf.org/html/draft-bertocci-oauth-access-token-jwt-00#ref-OpenID.Core>].
>>   See
>>   Section 3 
>> <https://tools.ietf.org/html/draft-bertocci-oauth-access-token-jwt-00#section-3>
>>  for indications on how an authorization server should
>>   determine the value of aud depending on the request.  [Note: some
>>   vendors seem to rely on resource aliases.  If we believe this to
>>   be a valuable feature, here's some proposed language: The aud
>>   claim MAY include a list of individual resource indicators if they
>>   are all aliases referring to the same requested resource known by
>>   the authorization server. ]
>>
>>
>>
>> I don't think OpenID.Core Section 3 is the correct reference for
>> determining the 'aud' value. The issue here is that the 'aud' of the
>> id_token is the recipient of the id_token (i.e. the client). However, for
>> access_tokens the 'aud' value should be the resource service that will
>> receive the access_token. There is no existing guidance for this and we
>> should provide such guidance as this is "kind of new" for OAuth2 (from an
>> explicit specification perspective).
>>
>> Also, there is the concept of 'azp' from the id_token which amounts to
>> "who's allowed to present this token" which might be interesting from the
>> case where one entity obtains the token, and gives it to another entity to
>> present. Not sure if we want to include this concept or not.
>>
>> Finally, I think we may need some best practice around how the concept of
>> audience and resource should be managed. For instance...
>>
>>If the request does not include a resource parameter, the
>>authorization server MUST use in the aud claim a default resource
>>indicator.  If a scope parameter is present in the request, the
>>authorization server SHOULD use it to infer the value of the default
>>resource indicator to be used in the aud claim.
>>
>>
>> I think for most implementations this would amount to... define an
>> audience that covers all the resource services where the access token can
>> be returned and set that as the audience (e.g. urn:x-mydomain:apis). Which
>> is perfectly legal but maybe not in the spirit of the spec:) I am receiving
>> feedback from developers that binding access tokens narrowly to the
>> resource where they will be presented is concerning from a chattiness
>> perspective (latency issues) and general load on the deployed AS
>> infrastructure.
>>
>> On 3/24/19 7:29 PM, Vittorio Bertocci wrote:
>>
>> Dear all,
>> I just submitted a draft describing a JWT profile for OAuth 2.0 access
>> tokens. You can find it in
>> https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/.
>> I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting
>> remotely). I look forward for your comments!
>>
>> Here's just a bit of backstory, in case you are interested in how this
>> doc came to be. The trajectory it followed is somewhat unusual.
>>
>>- Despite OAuth2 not requiring any specific format for ATs, through
>>the years I have come across multiple proprietary solution using JWT for
>>their access token. The intent and scenarios addressed by those solutions
>>are mostly the same across vendors, but the syntax and interpretations in
>>the implementations are different enough to prevent developers from 
>> reusing
>>code and skills when moving from product to product.
>>- I asked several individuals from key products and services to share
>>with me concrete examples of their JWT access tokens (THANK YOU Dominick
>>Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel
>>Dobalian (Microsoft), Karl Guinness (Okta) for the tokens and 
>> explanations!).
>>
>>I studied and compared all those instances,

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

[Brian Campbell]

Yeah, OpenID.Core isn't the right reference for `aud`.
https://tools.ietf.org/html/rfc7519#section-4.1.3 is the definition of
`aud` which should be the reference and this document can provide
additional specifics for the given application.

On Thu, Apr 4, 2019 at 8:07 AM George Fletcher  wrote:

> Another comment...
>
>aud  REQUIRED - as defined in section 2 of [OpenID.Core 
> <https://tools..ietf.org/html/draft-bertocci-oauth-access-token-jwt-00#ref-OpenID.Core>].
>   See
>   Section 3 
> <https://tools.ietf.org/html/draft-bertocci-oauth-access-token-jwt-00#section-3>
>  for indications on how an authorization server should
>   determine the value of aud depending on the request.  [Note: some
>   vendors seem to rely on resource aliases.  If we believe this to
>   be a valuable feature, here's some proposed language: The aud
>   claim MAY include a list of individual resource indicators if they
>   are all aliases referring to the same requested resource known by
>   the authorization server. ]
>
>
>
> I don't think OpenID.Core Section 3 is the correct reference for
> determining the 'aud' value. The issue here is that the 'aud' of the
> id_token is the recipient of the id_token (i.e. the client). However, for
> access_tokens the 'aud' value should be the resource service that will
> receive the access_token. There is no existing guidance for this and we
> should provide such guidance as this is "kind of new" for OAuth2 (from an
> explicit specification perspective).
>
> Also, there is the concept of 'azp' from the id_token which amounts to
> "who's allowed to present this token" which might be interesting from the
> case where one entity obtains the token, and gives it to another entity to
> present. Not sure if we want to include this concept or not.
>
> Finally, I think we may need some best practice around how the concept of
> audience and resource should be managed. For instance...
>
>If the request does not include a resource parameter, the
>authorization server MUST use in the aud claim a default resource
>indicator.  If a scope parameter is present in the request, the
>authorization server SHOULD use it to infer the value of the default
>resource indicator to be used in the aud claim.
>
>
> I think for most implementations this would amount to... define an
> audience that covers all the resource services where the access token can
> be returned and set that as the audience (e.g. urn:x-mydomain:apis). Which
> is perfectly legal but maybe not in the spirit of the spec:) I am receiving
> feedback from developers that binding access tokens narrowly to the
> resource where they will be presented is concerning from a chattiness
> perspective (latency issues) and general load on the deployed AS
> infrastructure.
>
> On 3/24/19 7:29 PM, Vittorio Bertocci wrote:
>
> Dear all,
> I just submitted a draft describing a JWT profile for OAuth 2.0 access
> tokens. You can find it in
> https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/.
> I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting
> remotely). I look forward for your comments!
>
> Here's just a bit of backstory, in case you are interested in how this doc
> came to be. The trajectory it followed is somewhat unusual.
>
>- Despite OAuth2 not requiring any specific format for ATs, through
>the years I have come across multiple proprietary solution using JWT for
>their access token. The intent and scenarios addressed by those solutions
>are mostly the same across vendors, but the syntax and interpretations in
>the implementations are different enough to prevent developers from reusing
>code and skills when moving from product to product.
>- I asked several individuals from key products and services to share
>with me concrete examples of their JWT access tokens (THANK YOU Dominick
>Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel Dobalian
>(Microsoft), Karl Guinness (Okta) for the tokens and explanations!).
>I studied and compared all those instances, identifying commonalities
>and differences.
>- I put together a presentation summarizing my findings and suggesting
>a rough interoperable profile (slides:
>
> https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx
>
> <https://sec..uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx>
>) - got early feedback from Filip Skokan on it. Thx Filip!
>- The presentation was followed up by 1.5 hours of unconference
>di

Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

[Brian Campbell]

+1 to David's question here. I'd like to see justifying use cases (beyond
just the fact that some people are already doing it) for auth_time, acr,
and amr to be available in OAuth JWT access tokens. Those claims are
defined for, and in the context of, an ID Token and I fear that codifying
their use in an access token will lead to misuse and/or confusion.

On Mon, Apr 1, 2019 at 1:03 PM David Waite 
wrote:

> Do we know if there is a justifying use case for auth_time, acr, and amr
> to be available in OAuth JWT access tokens? These are meant to be messages
> about the client, either directly (in the case of client credentials) or
> about its delegated authorization of the user.
>
> Embedding attributes about the user (such as group membership and roles)
> can be used for the resource to make finer-grained decisions than scopes,
> but normally I would expect say acr limitations enforced by a resource to
> instead be controlled by the AS requiring a higher quality authentication
> to release certain scopes.
>
> Thats of course not to say extensions to OAuth such as OIDC can’t provide
> these values, just that they might better be defined by those extensions.
>
> -DW
>
> On Apr 1, 2019, at 9:12 AM, George Fletcher <
> gffletch=40aol@dmarc.ietf.org> wrote:
>
> Thanks for writing this up. One comment on auth_time...
>
>auth_time  OPTIONAL - as defined in section 2 of [OpenID.Core 
> <https://tools.ietf.org/html/draft-bertocci-oauth-access-token-jwt-00#ref-OpenID.Core>].
>   Important: as this claim represents the time at which the end user
>   authenticated, its value will remain the same for all the JWT
>   access tokens issued within that session.  For example: all the
>   JWT access tokens obtained with a given refresh token will all
>   have the same value of auth_time, corresponding to the instant in
>   which the user first authenticated to obtain the refresh token.
>
>
> During a current session a user can be challenged for additional
> credentials or required to re-authenticate due to a number of different
> reasons. For example, OIDC prompt=login or max_age=NNN. In this context,
> I'd assume that the auth_time value should be updated to the latest time at
> which the user authenticated.
>
> If we need a timestamp for when the "session" started, then there could be
> a session_start_time claim.
>
> Thanks,
> George
>
> On 3/24/19 7:29 PM, Vittorio Bertocci wrote:
>
> Dear all,
> I just submitted a draft describing a JWT profile for OAuth 2.0 access
> tokens. You can find it in
> https://datatracker.ietf.org/doc/draft-bertocci-oauth-access-token-jwt/.
> I have a slot to discuss this tomorrow at IETF 104 (I'll be presenting
> remotely). I look forward for your comments!
>
> Here's just a bit of backstory, in case you are interested in how this doc
> came to be. The trajectory it followed is somewhat unusual.
>
>- Despite OAuth2 not requiring any specific format for ATs, through
>the years I have come across multiple proprietary solution using JWT for
>their access token. The intent and scenarios addressed by those solutions
>are mostly the same across vendors, but the syntax and interpretations in
>the implementations are different enough to prevent developers from reusing
>code and skills when moving from product to product.
>- I asked several individuals from key products and services to share
>with me concrete examples of their JWT access tokens (THANK YOU Dominick
>Baier (IdentityServer), Brian Campbell (PingIdentity), Daniel Dobalian
>(Microsoft), Karl Guinness (Okta) for the tokens and explanations!).
>I studied and compared all those instances, identifying commonalities
>and differences.
>- I put together a presentation summarizing my findings and suggesting
>a rough interoperable profile (slides:
>
> https://sec.uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx
>
> <https://sec..uni-stuttgart.de/_media/events/osw2019/slides/bertocci_-_a_jwt_profile_for_ats.pptx>
>) - got early feedback from Filip Skokan on it. Thx Filip!
>- The presentation was followed up by 1.5 hours of unconference
>discussion, which was incredibly valuable to get tight-loop feedback and
>incorporate new ideas. John Bradley, Brian Campbell Vladimir Dzhuvinov,
>Torsten Lodderstedt, Nat Sakimura, Hannes Tschofenig were all there
>and contributed generously to the discussion. Thank you!!!
>Note: if you were at OSW2019, participated in the discussion and
>didn't get credited in the draft, my apologies: please send me a note and
>I'll make things right at the nex

Re: [OAUTH-WG] draft-fett-oauth-dpop-00

[Brian Campbell]

Except that the jwk header is more appropriate in the given context
https://tools.ietf.org/html/rfc7515#section-4.1.3 - it is the public key
that corresponds to the key used to digitally sign the JWS.  Which is what
it is.



On Thu, Mar 28, 2019, 6:32 AM Mike Jones  wrote:

> Good observation, Ludwig.  We should do that.
>
> -- Mike
>
> -Original Message-
> From: OAuth  On Behalf Of Ludwig Seitz
> Sent: Thursday, March 28, 2019 12:05 PM
> To: oauth@ietf.org
> Subject: Re: [OAUTH-WG] draft-fett-oauth-dpop-00
>
> On 28/03/2019 11:17, Daniel Fett wrote:
> > Hi all,
> >
> > I published the first version of the DPoP draft at
> > https://tools.ietf.org/html/draft-fett-oauth-dpop-00
> >
> > Abstract
> >
> > This document defines a sender-constraint mechanism for OAuth 2.0
> > access tokens and refresh tokens utilizing an application-level
> > proof-of-possession mechanism based on public/private key pairs.
> >
> >
> > Thanks for the feedback I received so far from John, Mike, Torsten,
> > and others during today's session or before!
> >
> > If you find any errors I would welcome if you open an issue in the
> > GitHub repository at https://github.com/webhamster/draft-dpop
> >
> > - Daniel
> >
> >
>
> A quick nit:
>
> in figure 3 you seem to be using the "jwk" claim to include the pop-key in
> the token. Any reason for not using the "cnf" claim from RFC 7800?
>
> /Ludwig
>
>
> --
> Ludwig Seitz, PhD
> Security Lab, RISE
> Phone +46(0)70-349 92 51
>
> ___
> 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] Mentioning refresh tokens in MTLS' abstract

[Brian Campbell]

Your point about refresh tokens having a different threat model to access
tokens is taken, however, I think I'd stop short of saying a private key is
always at the same risk.

I will be at OSW next week and look forward to your presentation. Hopefully
it'll help me better understand the threat model and goals and constraints
and etc. you are working with.

As far as the document is concerned, there are folks that are interested in
the cert-binding of refresh tokens for public clients. So I don't it should
be removed. The text in -13 has a SHOULD for it so your case of not
cert-binding RTs is still within the lines of the spec. But perhaps that
SHOULD can be loosened and/or qualified somewhat so as to better
accommodate that case. I was trying to avoid it, but introducing a client
metadata flag to toggle the RT binding behavior is also a potential option.

On Thu, Mar 14, 2019 at 1:49 PM Neil Madden 
wrote:

> Comments in-line:
>
> On 14 Mar 2019, at 18:50, Brian Campbell 
> wrote:
>
> Certificate-binding refresh tokens issued to *public clients* (those that
> don't have authentication credentials established with the AS, a.k.a.
> clients configured or registered with the "none" authentication method,
> which will typically be native apps on a phone or similar) adds protections
> against malicious use or reuse of those refresh tokens where no protections
> would otherwise exist.
>
>
> Refresh tokens have a different threat model to access tokens as they are
> only communicated directly between the client and the AS over a secure
> channel. The main risk is of them being compromised on the client [*], but
> then a private key is at the same risk. Even if you generate the private
> key in a TPM on the device (eg mobile device with secure hardware), any
> malicious actor that is able to extract the refresh token from the client
> is also presumably in a position to either proxy requests through an
> existing TLS connection on that client or else interact with the TPM to
> create a new one.
>
> [*] Or by a compromise of TLS, but that breaks everything.
>
> It's true that certificate rotation in that situation would invalidate the
> refresh token. But not being able to rotate a strong asymmetric credential
> without invaliding the refresh token seems a very reasonable trade off vs..
> not having a credential bound to the token at all.
>
>
> I would not make that trade-off. If you are at OSW next week, I am
> presenting some cases for OAuth mTLS in a kubernetes environment that have
> public clients with long-lived grants that use refresh tokens to
> periodically rotate certs.
>
> I guess I would say that what is returned when introspecting such a
> refresh token is an implementation detail that is at the discretion of said
> implementation. That seems consistent with the level of guidance in
> introspection for refresh tokens currently. And there's not really an
> interoperability angle that I can see. So that seems fine. Also, some form
> of authorization is required to access the introspection endpoint so I'm
> not sure how a refresh token issued to a public client would realistically
> get introspected. I guess, if I'm being honest, I don't really get refresh
> token introspection in general so probably better that I stop opining on
> the subject.
>
>
> Ok, I’m happy to just ignore that aspect for refresh tokens then.
>
> — Neil
>
>
>
>
>
>
>
> On Thu, Mar 14, 2019 at 7:13 AM Neil Madden 
> wrote:
>
>> It’s not clear to me how this works or what problem it is solving. If a
>> refresh token is bound to the certificate, does that mean that a call to
>> the introspection endpoint with that refresh token should also return a
>> “cnf” claim as per
>> https://tools.ietf.org/html/draft-ietf-oauth-mtls-13#section-3.2 ?
>>
>> It also seems problematic to implement this for refresh tokens. As
>> mentioned by Filip, rotation of the certificate is out of the question.
>> Currently in our implementation a client could present a new certificate
>> when using the refresh token and this would result in the newly issued
>> access token being bound to the new certificate. If the refresh token is
>> bound to the original certificate, then this would be ruled out (the new
>> certificate would be rejected) and certificate rotation becomes impossible
>> in all cases. Am I missing something?
>>
>> — Neil
>>
>> > On 14 Mar 2019, at 12:28, Brian Campbell 
>> wrote:
>> >
>> > Yeah, so regular old RFC 6749 OAuth requires that a refresh token be
>> bound to the client to whom it was issued. And that confidential clients
>> (those having established auth

Re: [OAUTH-WG] Mentioning refresh tokens in MTLS' abstract

[Brian Campbell]

Certificate-binding refresh tokens issued to *public clients* (those that
don't have authentication credentials established with the AS, a.k.a.
clients configured or registered with the "none" authentication method,
which will typically be native apps on a phone or similar) adds protections
against malicious use or reuse of those refresh tokens where no protections
would otherwise exist. It's true that certificate rotation in that
situation would invalidate the refresh token. But not being able to rotate
a strong asymmetric credential without invaliding the refresh token seems a
very reasonable trade off vs. not having a credential bound to the token at
all.

I guess I would say that what is returned when introspecting such a refresh
token is an implementation detail that is at the discretion of said
implementation. That seems consistent with the level of guidance in
introspection for refresh tokens currently. And there's not really an
interoperability angle that I can see. So that seems fine. Also, some form
of authorization is required to access the introspection endpoint so I'm
not sure how a refresh token issued to a public client would realistically
get introspected. I guess, if I'm being honest, I don't really get refresh
token introspection in general so probably better that I stop opining on
the subject.






On Thu, Mar 14, 2019 at 7:13 AM Neil Madden 
wrote:

> It’s not clear to me how this works or what problem it is solving.. If a
> refresh token is bound to the certificate, does that mean that a call to
> the introspection endpoint with that refresh token should also return a
> “cnf” claim as per
> https://tools.ietf.org/html/draft-ietf-oauth-mtls-13#section-3.2 ?
>
> It also seems problematic to implement this for refresh tokens. As
> mentioned by Filip, rotation of the certificate is out of the question.
> Currently in our implementation a client could present a new certificate
> when using the refresh token and this would result in the newly issued
> access token being bound to the new certificate. If the refresh token is
> bound to the original certificate, then this would be ruled out (the new
> certificate would be rejected) and certificate rotation becomes impossible
> in all cases. Am I missing something?
>
> — Neil
>
> > On 14 Mar 2019, at 12:28, Brian Campbell 
> wrote:
> >
> > Yeah, so regular old RFC 6749 OAuth requires that a refresh token be
> bound to the client to whom it was issued. And that confidential clients
> (those having established authn credentials) authenticate to the AS when
> presenting a refresh token. Thus, for both MTLS methods of OAuth client
> authentication, refresh tokens are indirectly certificate-bound through
> their binding to a client and its credentials (and the client rotating its
> cert doesn't invalidate the refresh token).
> >
> > What was added in the -13 revision of the draft (in a new section
> https://tools.ietf.org/html/draft-ietf-oauth-mtls-13#section-4) was a
> brief description of certificate binding refresh tokens for public clients.
> >
> > The ask from Vittorio was a mention of refresh tokens in abstract. Which
> seems reasonable. But the proper wording to succinctly and accurately
> convey the aforementioned subtleties is proving difficult for me.
> >
> >
> >
> >
> >
> > On Thu, Mar 14, 2019 at 2:26 AM Neil Madden 
> wrote:
> > Right - this is what we have implemented. No support for
> certificate-bound refresh tokens, the client can be configured to require
> TLS cert client authentication instead.
> >
> > Neil
> >
> > On 14 Mar 2019, at 08:09, Filip Skokan  wrote:
> >
> >> Point being that since the refresh token is only usable on the IdP then
> mtls client auth already covers this, and since RTs are long-lasting, it
> does this better because cert rotation is possible for both mtls methods.
> >>
> >> S pozdravem,
> >> Filip Skokan
> >>
> >>
> >> On Thu, 14 Mar 2019 at 08:07, Filip Skokan  wrote:
> >> Even before refresh tokens were mentioned in draft 13 i was about to
> implement this binding in nodejs oidc-provider,
> >>
> >> the thing i struggled with and ultimately didn't do this was
> >>
> >> 1) if the refresh token is bound to a specific cert then this cert
> rotation is out of the question
> >> 2) if having the RT somehow covered is needed, isn't MTLS client auth
> already the right thing to do? Especially given it supports cert rotation
> >>
> >> Now the normative language is SHOULD therefore disallowing cert
> rotation. Or am I missing something?
> >>
> >> S pozdravem,
> >> Filip Skokan
&g

Re: [OAUTH-WG] Mentioning refresh tokens in MTLS' abstract

[Brian Campbell]

Yeah Filip, that's about right. Currently the text says to do it only for
public clients (clients using "none").

On Thu, Mar 14, 2019 at 6:53 AM Filip Skokan  wrote:

> Thank you for the clarification Brian, this makes sense.
>
> So for clients not using mtls (or is this only clients using "none"?) to
> authenticate the tls_client_certificate_bound_access_tokens client metadata
> property also conditions binding the refresh token. At the cost of the RT
> being unusable if the client loses or rotates the certificate.
>
> Best,
> *Filip*
>
>
> On Thu, 14 Mar 2019 at 13:29, Brian Campbell 
> wrote:
>
>> Yeah, so regular old RFC 6749 OAuth requires that a refresh token be
>> bound to the client to whom it was issued. And that confidential clients
>> (those having established authn credentials) authenticate to the AS when
>> presenting a refresh token. Thus, for both MTLS methods of OAuth client
>> authentication, refresh tokens are indirectly certificate-bound through
>> their binding to a client and its credentials (and the client rotating its
>> cert doesn't invalidate the refresh token).
>>
>> What was added in the -13 revision of the draft (in a new section
>> https://tools.ietf.org/html/draft-ietf-oauth-mtls-13#section-4) was a
>> brief description of certificate binding refresh tokens for public clients.
>>
>> The ask from Vittorio was a mention of refresh tokens in abstract. Which
>> seems reasonable. But the proper wording to succinctly and accurately
>> convey the aforementioned subtleties is proving difficult for me.
>>
>>
>>
>>
>>
>> On Thu, Mar 14, 2019 at 2:26 AM Neil Madden 
>> wrote:
>>
>>> Right - this is what we have implemented. No support for
>>> certificate-bound refresh tokens, the client can be configured to require
>>> TLS cert client authentication instead.
>>>
>>> Neil
>>>
>>> On 14 Mar 2019, at 08:09, Filip Skokan  wrote:
>>>
>>> Point being that since the refresh token is only usable on the IdP then
>>> mtls client auth already covers this, and since RTs are long-lasting, it
>>> does this better because cert rotation is possible for both mtls methods.
>>>
>>> S pozdravem,
>>> *Filip Skokan*
>>>
>>>
>>> On Thu, 14 Mar 2019 at 08:07, Filip Skokan >> > wrote:
>>>
>>>> Even before refresh tokens were mentioned in draft 13 i was about to
>>>> implement this binding in nodejs oidc-provider,
>>>>
>>>> the thing i struggled with and ultimately didn't do this was
>>>>
>>>> 1) if the refresh token is bound to a specific cert then this cert
>>>> rotation is out of the question
>>>> 2) if having the RT somehow covered is needed, isn't MTLS client auth
>>>> already the right thing to do? Especially given it supports cert rotation
>>>>
>>>> Now the normative language is SHOULD therefore disallowing cert
>>>> rotation. Or am I missing something?
>>>>
>>>> S pozdravem,
>>>> *Filip Skokan*
>>>>
>>>>
>>>> On Thu, 14 Mar 2019 at 00:21, Brian Campbell >>> 40pingidentity@dmarc.ietf.org> wrote:
>>>>
>>>>> As I kinda said on that call, I understand the ask and I do think it'd
>>>>> be reasonable to mention refresh tokens in the abstract now that the
>>>>> document does describe binding refresh tokens to the client certificate
>>>>> with public clients.
>>>>>
>>>>> I'm struggling to see the fix as pretty easy, however, given the text
>>>>> of the abstract (copied below for ease of reference) and the content and
>>>>> scope of the document.
>>>>>
>>>>> Do you think changing the first sentence to have "certificate-bound
>>>>> access and refresh tokens" is sufficient (and accurate)?
>>>>>
>>>>> Or something more or different? In which case proposed text is always
>>>>> welcome.
>>>>>
>>>>> Abstract
>>>>>
>>>>>This document describes OAuth client authentication and certificate-
>>>>>bound access tokens using mutual Transport Layer Security (TLS)
>>>>>authentication with X.509 certificates.  OAuth clients are provided a
>>>>>mechanism for authentication to the authorization server using mutual
>>>>>TLS, based on eith

Re: [OAUTH-WG] Draft Agenda for IETF104 OAuth WG meetings

[Brian Campbell]

There are icon links for audio and video next to the sessions on the agenda
at https://datatracker.ietf.org/meeting/104/agenda/. I believe registration
is required (but is free for remote participants). See
https://www.ietf.org/how/meetings/104/remote/ for more official
information.

Recordings will be available after the fact at some point on the
proceedings at https://datatracker.ietf.org/meeting/104/proceedings (here's
the the previous meeting's proceedings for example
https://datatracker.ietf.org/meeting/103/proceedings).

On Thu, Mar 14, 2019 at 2:17 AM Lars Wilhelmsen  wrote:

> Hi,
>
>
>
> Are these sessions recorded / available to follow online?
>
>
>
> Regards,
>
>   --larsw
>
>
>
> *From:* OAuth  *On Behalf Of *Rifaat Shekh-Yusef
> *Sent:* onsdag 13. mars 2019 18:46
> *To:* oauth 
> *Subject:* Re: [OAUTH-WG] Draft Agenda for IETF104 OAuth WG meetings
>
>
>
> Use the following links instead:
>
> https://datatracker.ietf.org/doc/agenda-104-oauth-sessa/
>
> https://datatracker.ietf.org/doc/agenda-104-oauth-sessb/
>
>
>
> Regards,
>
>  Rifaat
>
>
>
>
>
> On Wed, Mar 13, 2019 at 1:37 PM Rifaat Shekh-Yusef 
> wrote:
>
> All,
>
>
>
> The following links have our draft agenda for the two sessions:
>
>
>
>
> https://datatracker.ietf.org/meeting/104/materials/agenda-104-oauth-sessa-00
>
>
> https://datatracker.ietf.org/meeting/104/materials/agenda-104-oauth-sessb-00
>
>
>
> Please, take a look and let us know if you have any comments.
>
>
>
> Regards,
>
>  Rifaat & Hannes
>
>
>
> ___
> 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] Mentioning refresh tokens in MTLS' abstract

[Brian Campbell]

Yeah, so regular old RFC 6749 OAuth requires that a refresh token be bound
to the client to whom it was issued. And that confidential clients (those
having established authn credentials) authenticate to the AS when
presenting a refresh token. Thus, for both MTLS methods of OAuth client
authentication, refresh tokens are indirectly certificate-bound through
their binding to a client and its credentials (and the client rotating its
cert doesn't invalidate the refresh token).

What was added in the -13 revision of the draft (in a new section
https://tools.ietf.org/html/draft-ietf-oauth-mtls-13#section-4) was a brief
description of certificate binding refresh tokens for public clients.

The ask from Vittorio was a mention of refresh tokens in abstract. Which
seems reasonable. But the proper wording to succinctly and accurately
convey the aforementioned subtleties is proving difficult for me.





On Thu, Mar 14, 2019 at 2:26 AM Neil Madden 
wrote:

> Right - this is what we have implemented. No support for certificate-bound
> refresh tokens, the client can be configured to require TLS cert client
> authentication instead.
>
> Neil
>
> On 14 Mar 2019, at 08:09, Filip Skokan  wrote:
>
> Point being that since the refresh token is only usable on the IdP then
> mtls client auth already covers this, and since RTs are long-lasting, it
> does this better because cert rotation is possible for both mtls methods.
>
> S pozdravem,
> *Filip Skokan*
>
>
> On Thu, 14 Mar 2019 at 08:07, Filip Skokan  > wrote:
>
>> Even before refresh tokens were mentioned in draft 13 i was about to
>> implement this binding in nodejs oidc-provider,
>>
>> the thing i struggled with and ultimately didn't do this was
>>
>> 1) if the refresh token is bound to a specific cert then this cert
>> rotation is out of the question
>> 2) if having the RT somehow covered is needed, isn't MTLS client auth
>> already the right thing to do? Especially given it supports cert rotation
>>
>> Now the normative language is SHOULD therefore disallowing cert rotation..
>> Or am I missing something?
>>
>> S pozdravem,
>> *Filip Skokan*
>>
>>
>> On Thu, 14 Mar 2019 at 00:21, Brian Campbell > 40pingidentity@dmarc.ietf.org> wrote:
>>
>>> As I kinda said on that call, I understand the ask and I do think it'd
>>> be reasonable to mention refresh tokens in the abstract now that the
>>> document does describe binding refresh tokens to the client certificate
>>> with public clients.
>>>
>>> I'm struggling to see the fix as pretty easy, however, given the text of
>>> the abstract (copied below for ease of reference) and the content and scope
>>> of the document.
>>>
>>> Do you think changing the first sentence to have "certificate-bound
>>> access and refresh tokens" is sufficient (and accurate)?
>>>
>>> Or something more or different? In which case proposed text is always
>>> welcome.
>>>
>>> Abstract
>>>
>>>This document describes OAuth client authentication and certificate-
>>>bound access tokens using mutual Transport Layer Security (TLS)
>>>authentication with X.509 certificates.  OAuth clients are provided a
>>>mechanism for authentication to the authorization server using mutual
>>>TLS, based on either self-signed certificates or public key
>>>infrastructure (PKI).  OAuth authorization servers are provided a
>>>mechanism for binding access tokens to a client's mutual TLS
>>>certificate, and OAuth protected resources are provided a method for
>>>ensuring that such an access token presented to it was issued to the
>>>client presenting the token.
>>>
>>>
>>> On Mon, Mar 11, 2019 at 4:06 PM Vittorio Bertocci >> 40auth0@dmarc.ietf.org> wrote:
>>>
>>>> Hi all,
>>>> during today's office hours call I pointed out that oauth-mtls-13's 
>>>> abstract
>>>> only mentions access token, although the spec does provide (some) guidance
>>>> on  refresh token binding as well..
>>>> Although in the end implementers would do the right thing, given that
>>>> they have to read the spec in its entirety, having a mention of refresh
>>>> tokens in the abstract as well would make it easier for superficial readers
>>>> to learn that the spec does address RTs as well. Refresh tokens leakage is
>>>> one of the top concerns of the customers I deal with, and those people
>>>> rarely read specs from cover to cove

Re: [OAUTH-WG] Mentioning refresh tokens in MTLS' abstract

[Brian Campbell]

As I kinda said on that call, I understand the ask and I do think it'd be
reasonable to mention refresh tokens in the abstract now that the document
does describe binding refresh tokens to the client certificate with public
clients.

I'm struggling to see the fix as pretty easy, however, given the text of
the abstract (copied below for ease of reference) and the content and scope
of the document.

Do you think changing the first sentence to have "certificate-bound access
and refresh tokens" is sufficient (and accurate)?

Or something more or different? In which case proposed text is always
welcome.

Abstract

   This document describes OAuth client authentication and certificate-
   bound access tokens using mutual Transport Layer Security (TLS)
   authentication with X.509 certificates.  OAuth clients are provided a
   mechanism for authentication to the authorization server using mutual
   TLS, based on either self-signed certificates or public key
   infrastructure (PKI).  OAuth authorization servers are provided a
   mechanism for binding access tokens to a client's mutual TLS
   certificate, and OAuth protected resources are provided a method for
   ensuring that such an access token presented to it was issued to the
   client presenting the token.


On Mon, Mar 11, 2019 at 4:06 PM Vittorio Bertocci  wrote:

> Hi all,
> during today's office hours call I pointed out that oauth-mtls-13's abstract
> only mentions access token, although the spec does provide (some) guidance
> on  refresh token binding as well..
> Although in the end implementers would do the right thing, given that they
> have to read the spec in its entirety, having a mention of refresh tokens
> in the abstract as well would make it easier for superficial readers to
> learn that the spec does address RTs as well. Refresh tokens leakage is one
> of the top concerns of the customers I deal with, and those people rarely
> read specs from cover to cover: having language in the abstract explicitly
> calling out RTs might make some conversations easier.
>
> This is admittedly very minor, but the fix would also be pretty easy,
> ___
> 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] Client authentication in the Device Authorization Request

[Brian Campbell]

All sounds good to me. Thanks again for picking this one up quickly.

On Mon, Mar 11, 2019 at 2:43 PM William Denniss  wrote:

>
>
> On Mon, Mar 11, 2019 at 1:21 PM Brian Campbell  40pingidentity@dmarc.ietf.org> wrote:
>
>> And thank you, William, for being responsive about it.
>>
>>
>> On Mon, Mar 11, 2019 at 1:18 PM William Denniss > 40google@dmarc.ietf.org> wrote:
>>
>>> Thank you Brian for raising this.
>>>
>>> Yes, the expectation I believe is to follow the same approach as the
>>> token endpoint. As the spec is primarily for public clients, that's what we
>>> documented explicitly but it's worth calling out.
>>>
>>> Would the following text suffice in order to "inherit" the client
>>> authentication requirements of the token endpoint do you think?
>>>
>>> "The client authentication requirements of Section 3.2.1 of RFC6749
>>> apply to requests on this endpoint."
>>>
>>
>> I think so, yes.
>>
>> Although given the primary focus being for public clients, it might be
>> helpful to have a little qualifying text here catering to that most common
>> case. I guess I'm just looking to try and avoid folks mistakenly
>> interpreting that to mean that client authentication is always required and
>> so somehow public clients can't do this flow. Something like the following
>> (wording could maybe be improved but hopefully conveys the idea):
>>
>> 'The client authentication requirements of Section 3.2.1 of RFC6749 apply
>> to requests on this endpoint, which means that confidential clients (those
>> that have established client credentials) authenticate in the same manner
>> as when making requests to the token endpoint and public clients provide
>> the "client_id" parameter to identify themselves.'
>>
>>
>
> The context helps, thanks for the suggested text, I used it and it's
> staged locally now.
>
>
>>
>>
>>> Then there's the matter of the REQUIRED "client_id" parameter. Perhaps
>>> we could say "REQUIRED, unless the client authenticates per Section 2.3 of
>>> RFC6749"
>>>
>>
>> I kinda prefer the text you have already in section 3.4:
>>
>>   " client_id
>>   REQUIRED, if the client is not authenticating with the
>>   authorization server as described in Section 3.2.1. of [RFC6749]."
>>
>>
> hah yeah I prefer that construction too, forgot I'd already given it that
> treatment elsewhere.
>
> Also staged locally.
>
> Thanks again for reporting this!
>
>
>>
>>
>>>
>>> On Mon, Mar 11, 2019 at 10:30 AM Phil Hunt  wrote:
>>>
>>>> +1 to using same authentication requirements as for token endpoint.
>>>>
>>>> Phil
>>>>
>>>> On Mar 11, 2019, at 10:27 AM, George Fletcher <
>>>> gffletch=40aol@dmarc.ietf.org> wrote:
>>>>
>>>> +1
>>>>
>>>> to using the same client authn method as for the /token endpoint
>>>>
>>>> On 3/11/19 12:31 PM, Brian Campbell wrote:
>>>>
>>>>
>>>>
>>>> On Mon, Mar 11, 2019 at 10:22 AM Filip Skokan 
>>>> wrote:
>>>>
>>>>> Strike that, it should maybe just use the registered auth method for
>>>>> the token endpoint?
>>>>>
>>>>
>>>> Yeah, that's what I'd think would be the way to go.
>>>>
>>>>
>>>>>
>>>>> If there's auth we should also make it clear that client_id should not
>>>>> be omitted from the request body and it must be the same as the one
>>>>> provided with client authentication.
>>>>>
>>>>>
>>>> Fair point.
>>>>
>>>>
>>>>
>>>>
>>>>> S pozdravem,
>>>>> *Filip Skokan*
>>>>>
>>>>>
>>>>> On Mon, 11 Mar 2019 at 17:14, Filip Skokan  wrote:
>>>>>
>>>>>> If we're about to add client authentication for the
>>>>>> device_authorization_endpoint, i'd say we should also register for
>>>>>> device_authorization_endpoint_auth_method,
>>>>>> device_authorization_endpoint_auth_signing_alg client metadata. Maybe
>>>>>> define the default value to be "none" / not provided to be in line wi

Re: [OAUTH-WG] Client authentication in the Device Authorization Request

[Brian Campbell]

And thank you, William, for being responsive about it.


On Mon, Mar 11, 2019 at 1:18 PM William Denniss  wrote:

> Thank you Brian for raising this.
>
> Yes, the expectation I believe is to follow the same approach as the token
> endpoint. As the spec is primarily for public clients, that's what we
> documented explicitly but it's worth calling out.
>
> Would the following text suffice in order to "inherit" the client
> authentication requirements of the token endpoint do you think?
>
> "The client authentication requirements of Section 3.2.1 of RFC6749
> apply to requests on this endpoint."
>

I think so, yes.

Although given the primary focus being for public clients, it might be
helpful to have a little qualifying text here catering to that most common
case. I guess I'm just looking to try and avoid folks mistakenly
interpreting that to mean that client authentication is always required and
so somehow public clients can't do this flow. Something like the following
(wording could maybe be improved but hopefully conveys the idea):

'The client authentication requirements of Section 3.2.1 of RFC6749 apply
to requests on this endpoint, which means that confidential clients (those
that have established client credentials) authenticate in the same manner
as when making requests to the token endpoint and public clients provide
the "client_id" parameter to identify themselves.'



> Then there's the matter of the REQUIRED "client_id" parameter. Perhaps we
> could say "REQUIRED, unless the client authenticates per Section 2.3 of
> RFC6749"
>

I kinda prefer the text you have already in section 3.4:

  " client_id
  REQUIRED, if the client is not authenticating with the
  authorization server as described in Section 3.2.1. of [RFC6749]."



>
> On Mon, Mar 11, 2019 at 10:30 AM Phil Hunt  wrote:
>
>> +1 to using same authentication requirements as for token endpoint.
>>
>> Phil
>>
>> On Mar 11, 2019, at 10:27 AM, George Fletcher <
>> gffletch=40aol@dmarc.ietf.org> wrote:
>>
>> +1
>>
>> to using the same client authn method as for the /token endpoint
>>
>> On 3/11/19 12:31 PM, Brian Campbell wrote:
>>
>>
>>
>> On Mon, Mar 11, 2019 at 10:22 AM Filip Skokan  wrote:
>>
>>> Strike that, it should maybe just use the registered auth method for the
>>> token endpoint?
>>>
>>
>> Yeah, that's what I'd think would be the way to go.
>>
>>
>>>
>>> If there's auth we should also make it clear that client_id should not
>>> be omitted from the request body and it must be the same as the one
>>> provided with client authentication.
>>>
>>>
>> Fair point.
>>
>>
>>
>>
>>> S pozdravem,
>>> *Filip Skokan*
>>>
>>>
>>> On Mon, 11 Mar 2019 at 17:14, Filip Skokan  wrote:
>>>
>>>> If we're about to add client authentication for the
>>>> device_authorization_endpoint, i'd say we should also register for
>>>> device_authorization_endpoint_auth_method,
>>>> device_authorization_endpoint_auth_signing_alg client metadata. Maybe
>>>> define the default value to be "none" / not provided to be in line with the
>>>> late draft implementations. Wdyt?
>>>>
>>>> S pozdravem,
>>>> *Filip Skokan*
>>>>
>>>>
>>>> On Mon, 11 Mar 2019 at 17:08, Brian Campbell >>> 40pingidentity@dmarc.ietf.org> wrote:
>>>>
>>>>> I do realize it's very late in the process for this document but
>>>>> believe these omissions can be addressed in the document with only minor
>>>>> changes/additions and that it'd be better late than not at all..
>>>>>
>>>>> On Mon, Mar 11, 2019 at 10:03 AM Brian Campbell <
>>>>> bcampb...@pingidentity.com> wrote:
>>>>>
>>>>>> Another omission[1] (maybe, I believe it is anyway) to the Device
>>>>>> Flow is that client authentication isn't defined for the device
>>>>>> authorization request to device authorization endpoint.
>>>>>>
>>>>>> I suspect that it's largely an oversight because public clients are
>>>>>> really the conical use-case for the device flow and no authentication is
>>>>>> needed or possible in that case. There are, however, likely to be cases
>>>>>> where a client with credentials will do the dev

Re: [OAUTH-WG] Client authentication in the Device Authorization Request

[Brian Campbell]

On Mon, Mar 11, 2019 at 10:22 AM Filip Skokan  wrote:

> Strike that, it should maybe just use the registered auth method for the
> token endpoint?
>

Yeah, that's what I'd think would be the way to go.


>
> If there's auth we should also make it clear that client_id should not be
> omitted from the request body and it must be the same as the one provided
> with client authentication.
>
>
Fair point.




> S pozdravem,
> *Filip Skokan*
>
>
> On Mon, 11 Mar 2019 at 17:14, Filip Skokan  wrote:
>
>> If we're about to add client authentication for the
>> device_authorization_endpoint, i'd say we should also register for
>> device_authorization_endpoint_auth_method,
>> device_authorization_endpoint_auth_signing_alg client metadata. Maybe
>> define the default value to be "none" / not provided to be in line with the
>> late draft implementations. Wdyt?
>>
>> S pozdravem,
>> *Filip Skokan*
>>
>>
>> On Mon, 11 Mar 2019 at 17:08, Brian Campbell > 40pingidentity@dmarc.ietf.org> wrote:
>>
>>> I do realize it's very late in the process for this document but believe
>>> these omissions can be addressed in the document with only minor
>>> changes/additions and that it'd be better late than not at all..
>>>
>>> On Mon, Mar 11, 2019 at 10:03 AM Brian Campbell <
>>> bcampb...@pingidentity.com> wrote:
>>>
>>>> Another omission[1] (maybe, I believe it is anyway) to the Device Flow
>>>> is that client authentication isn't defined for the device authorization
>>>> request to device authorization endpoint.
>>>>
>>>> I suspect that it's largely an oversight because public clients are
>>>> really the conical use-case for the device flow and no authentication is
>>>> needed or possible in that case. There are, however, likely to be cases
>>>> where a client with credentials will do the device flow and it would be
>>>> good for the AS to be able to properly authenticate such clients before
>>>> setting up and saving the state for the transaction. Having normal client
>>>> authentication at device authorization endpoint also brings better
>>>> consistency to client identification/authentication for requests made
>>>> directly from client to AS.
>>>>
>>>>
>>>> [1] error responses from the device authorization endpoint should
>>>> probably also be defined
>>>> https://mailarchive.ietf.org/arch/msg/oauth/DMTUR1msdNQPiLh0xVXe39933k4
>>>>
>>>>
>>> *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
>

-- 
_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] Client authentication in the Device Authorization Request

[Brian Campbell]

I do realize it's very late in the process for this document but believe
these omissions can be addressed in the document with only minor
changes/additions and that it'd be better late than not at all.

On Mon, Mar 11, 2019 at 10:03 AM Brian Campbell 
wrote:

> Another omission[1] (maybe, I believe it is anyway) to the Device Flow is
> that client authentication isn't defined for the device authorization
> request to device authorization endpoint.
>
> I suspect that it's largely an oversight because public clients are really
> the conical use-case for the device flow and no authentication is needed or
> possible in that case. There are, however, likely to be cases where a
> client with credentials will do the device flow and it would be good for
> the AS to be able to properly authenticate such clients before setting up
> and saving the state for the transaction. Having normal client
> authentication at device authorization endpoint also brings better
> consistency to client identification/authentication for requests made
> directly from client to AS.
>
>
> [1] error responses from the device authorization endpoint should probably
> also be defined
> https://mailarchive.ietf.org/arch/msg/oauth/DMTUR1msdNQPiLh0xVXe39933k4
>
>

-- 
_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-WG] Client authentication in the Device Authorization Request

[Brian Campbell]

Another omission[1] (maybe, I believe it is anyway) to the Device Flow is
that client authentication isn't defined for the device authorization
request to device authorization endpoint.

I suspect that it's largely an oversight because public clients are really
the conical use-case for the device flow and no authentication is needed or
possible in that case. There are, however, likely to be cases where a
client with credentials will do the device flow and it would be good for
the AS to be able to properly authenticate such clients before setting up
and saving the state for the transaction. Having normal client
authentication at device authorization endpoint also brings better
consistency to client identification/authentication for requests made
directly from client to AS.


[1] error responses from the device authorization endpoint should probably
also be defined
https://mailarchive.ietf.org/arch/msg/oauth/DMTUR1msdNQPiLh0xVXe39933k4

-- 
_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] OAuth 2.0 Device flow error response

[Brian Campbell]

While probably not terribly important from an interoperability perspective,
I agree that does seem like an omission.

I took a quick look at our implementation and bad requests to the device
authorization endpoint will indeed return what is a standard OAuth 2.0
error response normally from the token endpoint with invalid_client or
invalid_scope error codes. And a little bit of poking at Google's device
authorization endpoint suggests it behaves similarly. I suspect it's pretty
typical.



On Fri, Mar 8, 2019 at 5:28 AM Emond Papegaaij 
wrote:

> Dear all,
>
> I'm working on an implementation of the OAuth 2.0 Device Flow for
> Browserless
> and Input Constrained Devices and noticed a possible omission in the spec..
> Section 3.2 describes the Device Authorization Response, but only the
> success
> response is specified, not the error response. I would have expected a
> standard OAuth 2.0 error response, probably with the following error
> codes:
> invalid_request, invalid_client and invalid_scope.
>
> Best regards,
> Emond Papegaaij
> Topicus KeyHub
>
>
> ___
> 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] draft-ietf-oauth-resource-indicators-02

[Brian Campbell]

It's not uncommon for a resource server (or API or protected resource) to
have a client id established with the AS. Typically that's used in the
context of the resource server acting as a client (and authenticating with
the AS) when calling the AS for access token introspection.  Using that id
as the audience of an access token is certainly a possibility. But for
other client's to know and use the client id of a resource server as the
value of ‘resource’ parameter seems somewhat awkward and unlikely to work
particularly well. Also the syntax of the values don't quite match up.
n
On Wed, Feb 27, 2019 at 12:46 AM Jaap Francke  wrote:

> Hi all,
>
> I have some questions/thoughts on the new draft for resource indicators.
> I didn’t do an in-depth study but would like to share my thoughts with you
> anyway.
>
> 1. In this draft, the Resource is identified by ‘resource’ parameter. For
> example, when the resource is an API, I would expect that API to validate
> the access_token at the resource server. The protocol for this would be
> based on the API’s client_id, so from that angle using the the client_id
> could be a different way to indicate the intended recipient of the access
> token.
>
> 2. I also think that the ‘resource’ parameter would be closely related to
> the “aud” claim specified by the OpenID Connect specifications. I think it
> is getting more and more common to use the OIDC-protocol “on top of OAuth”,
> so I’m wondering how the resource parameter would relate to that. The
> values of the ‘aud’ parameter are also client_id’s.
>
> Thanks in advance for responding to my views.
> Ciao!
>
> Jaap Francke
>
>
>
> On 26 Feb 2019, at 21:00, oauth-requ...@ietf.org wrote:
>
>draft-ietf-oauth-resource-indicators-02
>
>
> ___
> 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