Re: [OAUTH-WG] First Draft of OAuth 2.1

[Pedro Igor Silva]

I don't but people using our AS. As I mentioned, rotation for such clients
does not make sense but we had to deal with it.

I just wanted to bring an example of how rotation can't be added without a
significant impact on development and runtime experiences (as mentioned by
Vittorio) if considered for every scenario.

On Thu, Mar 12, 2020 at 5:57 PM Torsten Lodderstedt 
wrote:

> Then why are you rotating refresh tokens?
>
> Am 12.03.2020 um 20:48 schrieb Pedro Igor Silva :
>
> 
> A confidential client, as per the `web application` definition in Section
> `2.1.  Client Types`.
>
> On Thu, Mar 12, 2020 at 4:39 PM Torsten Lodderstedt <
> tors...@lodderstedt.net> wrote:
>
>> Is that a public client?
>>
>> Am 12.03.2020 um 20:32 schrieb Pedro Igor Silva :
>>
>> 
>> I agree with you and recently, we had to deal with an issue where a `web
>> application` using rotation (as defined by the draft) was having issues to
>> refresh tokens due to multiple concurrent requests at the moment a token is
>> about to expire or already expired. We had to add some controls to deal
>> with concurrency and additional complexity + performance penalties. And for
>> such clients, I was not sure whether or not rotation makes sense.
>>
>> On Thu, Mar 12, 2020 at 4:05 PM Vittorio Bertocci > 40auth0@dmarc.ietf.org> wrote:
>>
>>> Thanks for the clarification, Torsten.
>>> I believe it's the first time I see use of client credentials positioned
>>> as sender constraint; if the intent is saying that confidential clients
>>> should use their credentials when redeeming refresh tokens, I am of course
>>> in agreement but I think the language should be clearer and state the above
>>> explicitly.
>>>
>>> Re: failure frequency, I know of scenarios were the designers added
>>> rotation by default, and after a while it was turned to opt in because of
>>> the frequency of errors and impact on user experience/call center.
>>> I really believe that putting this as a MUST is justified only for
>>> exceedingly vulnerable situations, like SPAs.
>>> Native/desktop clients should be free to decide whether they want to opt
>>> in without loosing compliance. Just my 2 C
>>>
>>> On Thu, Mar 12, 2020 at 11:58 AM Torsten Lodderstedt >> 40lodderstedt@dmarc.ietf.org> wrote:
>>>
>>>> Hi,
>>>>
>>>> sender constraining refresh tokens for confidential client means client
>>>> authentication + check the binding of the refresh token with the respective
>>>> client id. I don’t think this is new as RFC6759 already required ASs to
>>>> check this binding. Assuming backends are generally confidential clients
>>>> also means no rotation and no cache synchronization needed.
>>>>
>>>> Rotation should be used for frontends, e.g. native apps and only if
>>>> there is there no other option. If a refresh fails, the app must go through
>>>> the authorization process again. That’s inconvenient so the question is how
>>>> often this happens. What I can say, I have never seen customer complaining
>>>> in several years of operation of ASs with refresh token rotation (including
>>>> replay detection) for native apps with millions of users.
>>>>
>>>> best regards,
>>>> Torsten.
>>>>
>>>> Am 12.03..2020 um 19:24 schrieb Vittorio Bertocci >>> 40auth0@dmarc.ietf.org>:
>>>>
>>>> 
>>>> Hey guys,
>>>> thanks for putting this together.
>>>> I am concerned with the real world impact of imposing sender
>>>> constraint | rotation as a MUST on refresh tokens in every scenario.
>>>> Sender constraint isn't immediately actionable - we just had the
>>>> discussion for dPOP, hence I won't go in the details here.
>>>> Rotation isn't something that can be added without significant impact
>>>> on development and runtime experiences:
>>>>
>>>>- on distributed scenarios, it introduces the need to serialize
>>>>access to shared caches
>>>>- network failures can lead to impact on experience- stranding
>>>>clients which fail to receive RTn+1 during RTn redemption in a limbo 
>>>> where
>>>>user interaction might become necessary, disrupting experience or
>>>>functionality for scenarios where the user isn't available to respond.
>>>>-
>>>>
>>>>
>>>&g

Re: [OAUTH-WG] First Draft of OAuth 2.1

[Pedro Igor Silva]

A confidential client, as per the `web application` definition in Section
`2.1.  Client Types`.

On Thu, Mar 12, 2020 at 4:39 PM Torsten Lodderstedt 
wrote:

> Is that a public client?
>
> Am 12.03.2020 um 20:32 schrieb Pedro Igor Silva :
>
> 
> I agree with you and recently, we had to deal with an issue where a `web
> application` using rotation (as defined by the draft) was having issues to
> refresh tokens due to multiple concurrent requests at the moment a token is
> about to expire or already expired. We had to add some controls to deal
> with concurrency and additional complexity + performance penalties. And for
> such clients, I was not sure whether or not rotation makes sense.
>
> On Thu, Mar 12, 2020 at 4:05 PM Vittorio Bertocci  40auth0@dmarc.ietf.org> wrote:
>
>> Thanks for the clarification, Torsten.
>> I believe it's the first time I see use of client credentials positioned
>> as sender constraint; if the intent is saying that confidential clients
>> should use their credentials when redeeming refresh tokens, I am of course
>> in agreement but I think the language should be clearer and state the above
>> explicitly.
>>
>> Re: failure frequency, I know of scenarios were the designers added
>> rotation by default, and after a while it was turned to opt in because of
>> the frequency of errors and impact on user experience/call center.
>> I really believe that putting this as a MUST is justified only for
>> exceedingly vulnerable situations, like SPAs.
>> Native/desktop clients should be free to decide whether they want to opt
>> in without loosing compliance. Just my 2 C
>>
>> On Thu, Mar 12, 2020 at 11:58 AM Torsten Lodderstedt > 40lodderstedt@dmarc.ietf.org> wrote:
>>
>>> Hi,
>>>
>>> sender constraining refresh tokens for confidential client means client
>>> authentication + check the binding of the refresh token with the respective
>>> client id. I don’t think this is new as RFC6759 already required ASs to
>>> check this binding. Assuming backends are generally confidential clients
>>> also means no rotation and no cache synchronization needed.
>>>
>>> Rotation should be used for frontends, e.g. native apps and only if
>>> there is there no other option. If a refresh fails, the app must go through
>>> the authorization process again. That’s inconvenient so the question is how
>>> often this happens. What I can say, I have never seen customer complaining
>>> in several years of operation of ASs with refresh token rotation (including
>>> replay detection) for native apps with millions of users.
>>>
>>> best regards,
>>> Torsten.
>>>
>>> Am 12.03..2020 um 19:24 schrieb Vittorio Bertocci >> 40auth0@dmarc.ietf.org>:
>>>
>>> 
>>> Hey guys,
>>> thanks for putting this together.
>>> I am concerned with the real world impact of imposing sender
>>> constraint | rotation as a MUST on refresh tokens in every scenario.
>>> Sender constraint isn't immediately actionable - we just had the
>>> discussion for dPOP, hence I won't go in the details here.
>>> Rotation isn't something that can be added without significant impact on
>>> development and runtime experiences:
>>>
>>>- on distributed scenarios, it introduces the need to serialize
>>>access to shared caches
>>>- network failures can lead to impact on experience- stranding
>>>clients which fail to receive RTn+1 during RTn redemption in a limbo 
>>> where
>>>user interaction might become necessary, disrupting experience or
>>>functionality for scenarios where the user isn't available to respond.
>>>-
>>>
>>>
>>>
>>> On Wed, Mar 11, 2020 at 5:28 PM Aaron Parecki >> > wrote:
>>>
>>>> I'm happy to share that Dick and Torsten and I have published a first
>>>> draft of OAuth 2.1. We've taken the feedback from the discussions on
>>>> the list and incorporated that into the draft.
>>>>
>>>> https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01
>>>>
>>>> A summary of the differences between this draft and OAuth 2.0 can be
>>>> found in section 12, and I've copied them here below.
>>>>
>>>> > This draft consolidates the functionality in OAuth 2.0 (RFC6749),
>>>> > OAuth 2.0 for Native Apps (RFC8252), Proof Key for Code Exchange
>>>> > (RFC7636), OAuth 2.0 for Browser-Based Apps
>

Re: [OAUTH-WG] First Draft of OAuth 2.1

[Pedro Igor Silva]

I agree with you and recently, we had to deal with an issue where a `web
application` using rotation (as defined by the draft) was having issues to
refresh tokens due to multiple concurrent requests at the moment a token is
about to expire or already expired. We had to add some controls to deal
with concurrency and additional complexity + performance penalties. And for
such clients, I was not sure whether or not rotation makes sense.

On Thu, Mar 12, 2020 at 4:05 PM Vittorio Bertocci  wrote:

> Thanks for the clarification, Torsten.
> I believe it's the first time I see use of client credentials positioned
> as sender constraint; if the intent is saying that confidential clients
> should use their credentials when redeeming refresh tokens, I am of course
> in agreement but I think the language should be clearer and state the above
> explicitly.
>
> Re: failure frequency, I know of scenarios were the designers added
> rotation by default, and after a while it was turned to opt in because of
> the frequency of errors and impact on user experience/call center.
> I really believe that putting this as a MUST is justified only for
> exceedingly vulnerable situations, like SPAs.
> Native/desktop clients should be free to decide whether they want to opt
> in without loosing compliance. Just my 2 C
>
> On Thu, Mar 12, 2020 at 11:58 AM Torsten Lodderstedt  40lodderstedt@dmarc.ietf.org> wrote:
>
>> Hi,
>>
>> sender constraining refresh tokens for confidential client means client
>> authentication + check the binding of the refresh token with the respective
>> client id. I don’t think this is new as RFC6759 already required ASs to
>> check this binding. Assuming backends are generally confidential clients
>> also means no rotation and no cache synchronization needed.
>>
>> Rotation should be used for frontends, e.g. native apps and only if there
>> is there no other option. If a refresh fails, the app must go through the
>> authorization process again. That’s inconvenient so the question is how
>> often this happens. What I can say, I have never seen customer complaining
>> in several years of operation of ASs with refresh token rotation (including
>> replay detection) for native apps with millions of users.
>>
>> best regards,
>> Torsten.
>>
>> Am 12.03..2020 um 19:24 schrieb Vittorio Bertocci > 40auth0@dmarc.ietf.org>:
>>
>> 
>> Hey guys,
>> thanks for putting this together.
>> I am concerned with the real world impact of imposing sender constraint |
>> rotation as a MUST on refresh tokens in every scenario.
>> Sender constraint isn't immediately actionable - we just had the
>> discussion for dPOP, hence I won't go in the details here.
>> Rotation isn't something that can be added without significant impact on
>> development and runtime experiences:
>>
>>- on distributed scenarios, it introduces the need to serialize
>>access to shared caches
>>- network failures can lead to impact on experience- stranding
>>clients which fail to receive RTn+1 during RTn redemption in a limbo where
>>user interaction might become necessary, disrupting experience or
>>functionality for scenarios where the user isn't available to respond..
>>-
>>
>>
>>
>> On Wed, Mar 11, 2020 at 5:28 PM Aaron Parecki > > wrote:
>>
>>> I'm happy to share that Dick and Torsten and I have published a first
>>> draft of OAuth 2.1. We've taken the feedback from the discussions on
>>> the list and incorporated that into the draft.
>>>
>>> https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01
>>>
>>> A summary of the differences between this draft and OAuth 2.0 can be
>>> found in section 12, and I've copied them here below.
>>>
>>> > This draft consolidates the functionality in OAuth 2.0 (RFC6749),
>>> > OAuth 2.0 for Native Apps (RFC8252), Proof Key for Code Exchange
>>> > (RFC7636), OAuth 2.0 for Browser-Based Apps
>>> > (I-D.ietf-oauth-browser-based-apps), OAuth Security Best Current
>>> > Practice (I-D.ietf-oauth-security-topics), and Bearer Token Usage
>>> > (RFC6750).
>>> >
>>> >   Where a later draft updates or obsoletes functionality found in the
>>> >   original [RFC6749], that functionality in this draft is updated with
>>> >   the normative changes described in a later draft, or removed
>>> >   entirely.
>>> >
>>> >   A non-normative list of changes from OAuth 2.0 is listed below:
>>> >
>>> >   *  The authorization code grant is extended with the functionality
>>> >  from PKCE ([RFC7636]) such that the only method of using the
>>> >  authorization code grant according to this specification requires
>>> >  the addition of the PKCE mechanism
>>> >
>>> >   *  Redirect URIs must be compared using exact string matching as per
>>> >  Section 4.1.3 of [I-D.ietf-oauth-security-topics]
>>> >
>>> >   *  The Implicit grant ("response_type=token") is omitted from this
>>> >  specification as per Section 2.1.2 of
>>> >  [I-D.ietf-oauth-security-topics]
>>> >
>>> >   *  The Resource Owner Password 

Re: [OAUTH-WG] Transaction Authorization with OAuth (Torsten Lodderstedt)

[Pedro Igor Silva]

Hi Jaap,

Very good points. I have the same opinion about what you said about the
meaning of scopes (and how people are actually using them), the
resource-scope relationship and the importance of a standardized way of
doing this form of authorization to address different use cases, not only
delegation. Like George said in one of his messages, both 1st and 3rd party
use cases could be considered by a solution like that.

I would love to see something based on OAuth like this:

#1) Client tries to access a protected resource. At this point, the client
does not yet have a bearer token or the bearer token is lacking the
required scopes/permissions. The resource server responds with:

*HTTP/1.1 403 Unauthorized *
*WWW-Authenticate: Bearer realm="example",
error="invalid_token",
claim_token="accVkjcJyb4BWCxGsndESCJQbdFMogUC5PbRDqceLTC"*

The claim_token response parameter returned by the resource server
represents all the security constraints (e.g.: scopes) and information
(e.g.: contextual) that the client needs in order to obtain a valid access
token from the AS. This token can be built by the RS or even use some
endpoint at the AS, as UMA does. It can be just a reference token too.

#2) Client obtains an access token from the token endpoint at the AS:

*POST /as/token.oauth2 HTTP/1.1*
*Host: as.example.com *
*Content-Type: application/x-www-form-urlencoded*
*grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Apermission*
*&resource=https%3A%2F%2Fbackend.example.com
%2Fapi%20*
*&claim_token=accVkjcJyb4BWCxGsndESCJQbdFMogUC5PbRDqceLTC*
*&subject_token=accVkjcJyb4BWCxGsndESCJQbdFMogUC5PbRDqceLTC*
*&subject_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aaccess_token*

The example above shows a client request to the token endpoint when the
client already has an access token and wants a new token with permissions
to access a resource.

#3) Just like any other OAuth grant type, the token endpoint responds to
the client as follows (success):

*HTTP/1.1 200 OK*
*Content-Type: application/json;charset=UTF-8*
*Cache-Control: no-store*
*Pragma: no-cache*

*{*
*"access_token":"2YotnFZFEjr1zCsicMWpAA"*
*"token_type":"example",*
*"expires_in":3600,*
*"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"*
*} *

#4) Clients can now access protected resources using the access token with
all permissions granted by the server

It is not coincidence the similarities with and the usage of specs/drafts
like token exchange, resource-indicator, UMA, Lodging Intent Pattern, or
even ACE's "AS Request Creation Hints" message. The point I would like to
make is that we could leverage the standards/specs that exist today to
address the problem without reinventing the wheel.

There are very interesting things in UMA specs that can be used here too,
such as the possibility to perform incremental authorization or token
upgrade, etc.

Regards.
Pedro Igor

On Thu, Apr 25, 2019 at 4:27 AM Jaap Francke  wrote:

> Hi Torsten and others,
>
> I just read your blog - having “we need to re-think OAuth scopes” in the
> title immediately drew my attention.
> I find this interesting since I’m struggling with the concept of scopes
> from time-to-time.
> I’ll have to read the blog a few times more to get a good understanding,
> but I would like to share some of my thoughts on scopes.
>
> I believe the OAuth scope concept has it’s limitations not only for
> transactions but also for the more traditional ‘resource’ concept.
> RFC 6749 defines scopes as follows:
> "The value of the scope parameter is expressed as a list of space-
>delimited, case-sensitive strings.  The strings are defined by the
>authorization server.  If the value contains multiple space-delimited
>strings, their order does not matter, and each string adds an
>additional access range to the requested scope.”
>
> I see 2 aspects in this definition:
> - how the strings should look like is beyond the scope of the RFC
> - each string adds an additional authorisation
>
> Scopes are associated with access_tokens, which typically are bearer
> tokens as defined by RFC 6750 as:
>   A security token with the property that any party in possession of
>   the token (a "bearer") can use the token in any way that any other
>   party in possession of it can.  Using a bearer token does not
>   require a bearer to prove possession of cryptographic key material
>   (proof-of-possession).”
>
> This implies that every scope value should fully describe the
> authorisation that is given. In my view that is rarely done, which is the
> main reason why I find myself struggling with scope-concept.
>
> Here we have a collection of examples, which demonstrate to me that
> everyone is inventing their own wheels according to their specfic needs:
> https://brandur.org/oauth-scope
> https://api.slack.com/docs/oauth-scopes
>
> In various other (draft) standards I see bits and pieces that seem to
> address this issue.
>
> In UMA an authori

Re: [OAUTH-WG] Transaction Authorization with OAuth

[Pedro Igor Silva]

I think this knowledge by clients of the ecosystem is something that a
transactional authorization could avoid. Both UMA and ACE have solutions
that make clients really dumb about what they need to send to the AS in
regards to scopes. IMO, the RS should have the possibility to tell clients
the scope they need, making a lot easier to change RS's access constraints
as well as pushing contextual information that could eventually enrich the
authorization process.

On Mon, Apr 22, 2019 at 4:04 PM George Fletcher  wrote:

> Speaking just to the UMA side of things...
>
> ...it's possible in UMA 2 for the client to request additional scopes when
> interacting with the token endpoint specifically to address cases where the
> client knows it's going to make the following requests and wants to obtain
> a token with sufficient privilege for those requests. This requires a fair
> amount of knowledge by the client of the ecosystem but that is sometimes
> the case and hence this capability exists :)
>
> On 4/22/19 1:18 PM, Torsten Lodderstedt wrote:
>
> The problem from my perspective (and my understanding of UMA) is the RS does 
> not have any information about the context of the request. For example, the 
> client might be calling a certain resource (list of accounts) and immediately 
> afterwards wants to obtain the balances and initiate a payment. I think the 
> UMA case the RS either predicts this based on policy or past behaviour of the 
> client OR the client will need to issue several token requests. That might 
> not be a problem in 1st party scenarios but it is in 3rd party scenarios if 
> the AS gathers consent.
>
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Transaction Authorization with OAuth

[Pedro Igor Silva]

Sorry. I mean, UMA provides much more than this 1st party authorization
flow I'm talking about 

On Mon, Apr 22, 2019 at 2:51 PM Pedro Igor Silva  wrote:

>
>
> On Mon, Apr 22, 2019 at 2:18 PM Torsten Lodderstedt <
> tors...@lodderstedt.net> wrote:
>
>> Hi Pedro,
>>
>> >
>> > > The general idea is to empower RSs so that they can communicate to
>> the AS how access to their resources should be granted as well as
>> decoupling clients and RSs so that clients don't need to know the
>> constraints imposed by the RS to their protected resources (e.g. scopes)..
>> >
>> > Sounds very much like UMA2. The difference I see is the RS needs to be
>> heavily involved in the authorization process (whereas the approaches I
>> discussed leave it passive). How would you handle the use cases I
>> described? So for example, how would you construct the JWT for the
>> signature use case? I’m asking because the signing case uses more data in
>> the authorization process and might bundle the request to sign multiple
>> documents, even if the first signing request would only need the hashes or
>> even just a single hash of a document.
>> >
>> > Yes, it does. Like I mentioned, the model is based on UMA (Permission
>> Ticket/API) as well as ACE (Unauthorized Resource Request Message). I had
>> talked with UMA WG in the past about this solution and how we extended the
>> specs to solve this type of problem.
>> >
>> > By being active during the authorization process the RS is in control
>> over additional claims that should be considered by the policies when
>> making decisions about the resources/scopes a client/user can access. Where
>> the information could be obtained from different sources such as the
>> current HTTP request or internally/externally to the RS.
>>
>> The problem from my perspective (and my understanding of UMA) is the RS
>> does not have any information about the context of the request. For
>> example, the client might be calling a certain resource (list of accounts)
>> and immediately afterwards wants to obtain the balances and initiate a
>> payment. I think the UMA case the RS either predicts this based on policy
>> or past behaviour of the client OR the client will need to issue several
>> token requests. That might not be a problem in 1st party scenarios but it
>> is in 3rd party scenarios if the AS gathers consent.
>>
>
> Yeah, we are talking about different use cases. But they are still quite
> related in regards to enriching authorization decisions. it would be nice
> to have something in OAuth that could address both 1st and 3rd party use
> cases. As I said before, the model I'm talking about is kind of a 1st party
> Lodging_Intent.
>
> Just to clarify, UMA does not cover the scenario I'm talking about
> although it provides a very good ground for extensions like this. It is not
> part of UMA scope. It provides much more than that too ...
>
>
>>
>> >
>> > We did not have much demand for addressing the signature use case, but
>> use cases similar to the "payment" use case. As I mentioned, the model I'm
>> talking about is not based on user consent.
>>
>> Right, you mentioned it is intended to be used for 1st parties only.
>>
>> > But considering that you can also pass any information to the AS, you
>> should be able to let users to authorize the creation of signatures for one
>> or more documents.
>>
>> I think the client needs to pass this information, which brings us back
>> to the original question of my article.
>>
>> best regards.
>> Torsten.
>>
>> >
>> >
>> > >
>> > > I've started to write a document with this idea in mind and I'm happy
>> to share it with you and see what you think.
>> > >
>> >
>> > Look forward to reading your article.
>> >
>> > best regards,
>> > Torsten.
>> >
>> > > Best regards.
>> > > Pedro Igor
>> > >
>> > > On Sat, Apr 20, 2019 at 3: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
>> >
>>
>>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Transaction Authorization with OAuth

[Pedro Igor Silva]

On Mon, Apr 22, 2019 at 2:18 PM Torsten Lodderstedt 
wrote:

> Hi Pedro,
>
> >
> > > The general idea is to empower RSs so that they can communicate to the
> AS how access to their resources should be granted as well as decoupling
> clients and RSs so that clients don't need to know the constraints imposed
> by the RS to their protected resources (e.g. scopes).
> >
> > Sounds very much like UMA2. The difference I see is the RS needs to be
> heavily involved in the authorization process (whereas the approaches I
> discussed leave it passive). How would you handle the use cases I
> described? So for example, how would you construct the JWT for the
> signature use case? I’m asking because the signing case uses more data in
> the authorization process and might bundle the request to sign multiple
> documents, even if the first signing request would only need the hashes or
> even just a single hash of a document.
> >
> > Yes, it does. Like I mentioned, the model is based on UMA (Permission
> Ticket/API) as well as ACE (Unauthorized Resource Request Message). I had
> talked with UMA WG in the past about this solution and how we extended the
> specs to solve this type of problem.
> >
> > By being active during the authorization process the RS is in control
> over additional claims that should be considered by the policies when
> making decisions about the resources/scopes a client/user can access. Where
> the information could be obtained from different sources such as the
> current HTTP request or internally/externally to the RS.
>
> The problem from my perspective (and my understanding of UMA) is the RS
> does not have any information about the context of the request. For
> example, the client might be calling a certain resource (list of accounts)
> and immediately afterwards wants to obtain the balances and initiate a
> payment. I think the UMA case the RS either predicts this based on policy
> or past behaviour of the client OR the client will need to issue several
> token requests. That might not be a problem in 1st party scenarios but it
> is in 3rd party scenarios if the AS gathers consent.
>

Yeah, we are talking about different use cases. But they are still quite
related in regards to enriching authorization decisions. it would be nice
to have something in OAuth that could address both 1st and 3rd party use
cases. As I said before, the model I'm talking about is kind of a 1st party
Lodging_Intent.

Just to clarify, UMA does not cover the scenario I'm talking about although
it provides a very good ground for extensions like this. It is not part of
UMA scope. It provides much more than that too ...


>
> >
> > We did not have much demand for addressing the signature use case, but
> use cases similar to the "payment" use case. As I mentioned, the model I'm
> talking about is not based on user consent.
>
> Right, you mentioned it is intended to be used for 1st parties only.
>
> > But considering that you can also pass any information to the AS, you
> should be able to let users to authorize the creation of signatures for one
> or more documents.
>
> I think the client needs to pass this information, which brings us back to
> the original question of my article.
>
> best regards.
> Torsten.
>
> >
> >
> > >
> > > I've started to write a document with this idea in mind and I'm happy
> to share it with you and see what you think.
> > >
> >
> > Look forward to reading your article.
> >
> > best regards,
> > Torsten.
> >
> > > Best regards.
> > > Pedro Igor
> > >
> > > On Sat, Apr 20, 2019 at 3: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
> >
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Transaction Authorization with OAuth

[Pedro Igor Silva]

On Mon, Apr 22, 2019 at 1:33 PM Torsten Lodderstedt 
wrote:

> Hi Pedro,
>
> > On 22. Apr 2019, at 16:34, Pedro Igor Silva  wrote:
> >
> > Hi Torsten,
> >
> > Great article, thanks for sharing it.
>
> my pleasure :-)
>
> >
> > We have been working on a solution for fine-grained authorization using
> OAuth2 but specific for first-party applications where the granted
> permissions/scopes depend on the policies associated with the
> resources/scopes a client is trying to access. We don't have extensions to
> the authorization endpoint but a specific grant type for this purpose on
> the token endpoint.
> >
> > The solution is similar to the Lodging Intent Pattern but also based on
> specific parts of UMA and ACE.
> >
> > Basically, when a client first tries to access a protected resource the
> RS will respond with all the information the client needs to obtain a valid
> token from the AS. The information returned by the RS can be a
> signed/encrypted JWT or just a reference that later the AS can use to
> actually fetch the information. With this information in hands, clients can
> then approach the AS in order to obtain an access token with the
> permissions to access the protected resource.
> >
> > The general idea is to empower RSs so that they can communicate to the
> AS how access to their resources should be granted as well as decoupling
> clients and RSs so that clients don't need to know the constraints imposed
> by the RS to their protected resources (e.g. scopes).
>
> Sounds very much like UMA2. The difference I see is the RS needs to be
> heavily involved in the authorization process (whereas the approaches I
> discussed leave it passive). How would you handle the use cases I
> described? So for example, how would you construct the JWT for the
> signature use case? I’m asking because the signing case uses more data in
> the authorization process and might bundle the request to sign multiple
> documents, even if the first signing request would only need the hashes or
> even just a single hash of a document.
>

Yes, it does. Like I mentioned, the model is based on UMA (Permission
Ticket/API) as well as ACE (Unauthorized Resource Request Message). I had
talked with UMA WG in the past about this solution and how we extended the
specs to solve this type of problem.

By being active during the authorization process the RS is in control over
additional claims that should be considered by the policies when making
decisions about the resources/scopes a client/user can access. Where the
information could be obtained from different sources such as the current
HTTP request or internally/externally to the RS.

We did not have much demand for addressing the signature use case, but use
cases similar to the "payment" use case. As I mentioned, the model I'm
talking about is not based on user consent. But considering that you can
also pass any information to the AS, you should be able to let users to
authorize the creation of signatures for one or more documents.


>
> >
> > I've started to write a document with this idea in mind and I'm happy to
> share it with you and see what you think.
> >
>
> Look forward to reading your article.
>
> best regards,
> Torsten.
>
> > Best regards.
> > Pedro Igor
> >
> > On Sat, Apr 20, 2019 at 3: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
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Transaction Authorization with OAuth

[Pedro Igor Silva]

Yeah, I did.

XACML is a good standard, even better after v3. We do have options to
leverage XACML policy language model to write policies, but protocol-wise,
something on top of OAuth, would be very nice. As an authorization
framework, fine-grained/contextual authorization seems to be a natural
addition to OAuth.

Regards.
Pedro Igor

On Mon, Apr 22, 2019 at 1:11 PM Jim Manico  wrote:

> Have you looked at other standards that address find grained access
> control like NIST ABAC or XACML? This is a somewhat solved issue and I
> wonder if previous work can be leveraged.
>
> A basic string “scope” is certainly not enough to represent and transport
> complex authorization policy. I would imagine that something closer to
> XACML would work.
>
> --
> Jim Manico
> @Manicode
>
> On Apr 22, 2019, at 9:34 AM, Pedro Igor Silva  wrote:
>
> Hi Torsten,
>
> Great article, thanks for sharing it.
>
> We have been working on a solution for fine-grained authorization using
> OAuth2 but specific for first-party applications where the granted
> permissions/scopes depend on the policies associated with the
> resources/scopes a client is trying to access. We don't have extensions to
> the authorization endpoint but a specific grant type for this purpose on
> the token endpoint.
>
> The solution is similar to the Lodging Intent Pattern but also based on
> specific parts of UMA and ACE.
>
> Basically, when a client first tries to access a protected resource the RS
> will respond with all the information the client needs to obtain a valid
> token from the AS. The information returned by the RS can be a
> signed/encrypted JWT or just a reference that later the AS can use to
> actually fetch the information. With this information in hands, clients can
> then approach the AS in order to obtain an access token with the
> permissions to access the protected resource.
>
> The general idea is to empower RSs so that they can communicate to the AS
> how access to their resources should be granted as well as decoupling
> clients and RSs so that clients don't need to know the constraints imposed
> by the RS to their protected resources (e.g. scopes).
>
> I've started to write a document with this idea in mind and I'm happy to
> share it with you and see what you think.
>
> Best regards.
> Pedro Igor
>
> On Sat, Apr 20, 2019 at 3: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
>> <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
>>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Transaction Authorization with OAuth

[Pedro Igor Silva]

Hi Torsten,

Great article, thanks for sharing it.

We have been working on a solution for fine-grained authorization using
OAuth2 but specific for first-party applications where the granted
permissions/scopes depend on the policies associated with the
resources/scopes a client is trying to access. We don't have extensions to
the authorization endpoint but a specific grant type for this purpose on
the token endpoint.

The solution is similar to the Lodging Intent Pattern but also based on
specific parts of UMA and ACE.

Basically, when a client first tries to access a protected resource the RS
will respond with all the information the client needs to obtain a valid
token from the AS. The information returned by the RS can be a
signed/encrypted JWT or just a reference that later the AS can use to
actually fetch the information. With this information in hands, clients can
then approach the AS in order to obtain an access token with the
permissions to access the protected resource.

The general idea is to empower RSs so that they can communicate to the AS
how access to their resources should be granted as well as decoupling
clients and RSs so that clients don't need to know the constraints imposed
by the RS to their protected resources (e.g. scopes).

I've started to write a document with this idea in mind and I'm happy to
share it with you and see what you think.

Best regards.
Pedro Igor

On Sat, Apr 20, 2019 at 3:21 PM Torsten Lodderstedt 
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
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Access Tokens

[Pedro Igor Silva]

+1 plus Anthony's caveats.

The draft seems to provide a good reference for implementors by providing
how different ASes are using JWT as the access token format. As well as
providing valuable information about validation and security considerations..

Regards.
Pedro Igor

On Wed, Apr 10, 2019 at 8:12 AM Anthony Nadalin  wrote:

> I support adoption of this draft as a working group document with the
> following caveats:
>
> 1. These are not to be used as ID Tokens/authentication tokens
> 2. The privacy issues must be addressed
> 3. Needs to be extensible, much like ID-Token, can't be 100% fixed
>
>
> -Original Message-
> From: OAuth  On Behalf Of Hannes Tschofenig
> Sent: Monday, April 8, 2019 10:07 AM
> To: oauth@ietf.org
> Subject: [OAUTH-WG] Call for adoption: JWT Usage in OAuth2 Access Tokens
>
> Hi all,
>
> this is the call for adoption of the 'JWT Usage in OAuth2 Access Tokens'
> document following the positive feedback at the last IETF meeting in Prague.
>
> Here is the document:
>
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools..ietf.org%2Fhtml%2Fdraft-bertocci-oauth-access-token-jwt-00&data=02%7C01%7Ctonynad%40microsoft.com%7Ca3d9527e05364fa8578b08d6bc44b170%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636903400616347061&sdata=ePmwaD%2FHCRZhRx%2FwZbb3U72%2FhBalPoFPKtQ67QTxIRw%3D&reserved=0
>
> Please let us know by April 22nd whether you accept / object to the
> adoption of this document as a starting point for work in the OAuth working
> group.
>
> 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7Ctonynad%40microsoft.com%7Ca3d9527e05364fa8578b08d6bc44b170%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636903400616357060&sdata=zcxw1IR3kNbuZ9u58OOJDv9pLb7cUCooDtlIUH7tS%2Fw%3D&reserved=0
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] feedback on draft-ietf-oauth-browser-based-apps-00

[Pedro Igor Silva]

Hi,

I've seem some implementations where the token is not directly delivered to
the browser by the backend, but some temporary UUID that later the SPA can
exchange for an access token.

Do you think this is a good approach to the recommendation you are
discussing?

In addition to that, could you clarify more what would be the limitations
that ASes may wish to impose to these clients?

Regards.
Pedro Igor

On Tue, Apr 2, 2019 at 1:10 PM George Fletcher  wrote:

> I think it's fair to call it out (either in the paragraph here or in the
> security considerations). The issue is that the security aspect of the
> access token ending up in the browser is probably true in many contexts
> other than SPAs:)
>
> What about something like...
>
> In this scenario, the backend component is likely a confidential client
> which is issued it's own client secret. Note that in this model, the
> access_token obtained by the backend component will be delivered to the
> browser for use by the SPA so is more exposed than in the classic
> confidential client model. Some Authorization Servers may wish to limit the
> capabilities of these clients due to risk considerations.
>
> ... or something like that.
>
> On 4/2/19 11:57 AM, Aaron Parecki wrote:
>
> Thanks, this is a good question. I was talking with someone about this
> draft the other day and had the same question myself. Re-reading RFC6749,
> "public client" does describe only the limitation of the client protecting
> its own credentials, so I think you're right that this paragraph is
> misleading. However I suspect that some ASs will still want to treat
> clients where the access token ends up in the browser differently. Is that
> a fair assessment? I think the fix to this paragraph would be a slight
> rewording to just remove the mention of public clients.
>
> Aaron
>
>
> On Tue, Apr 2, 2019 at 8:53 AM George Fletcher  wrote:
>
>> Hi,
>>
>> In section 6.2 the following statement is made...
>>
>>In this scenario, the backend component may be a confidential client
>>which is issued its own client secret.  Despite this, there are still
>>some ways in which this application is effectively a public client,
>>as the end result is the application's code is still running in the
>>browser and visible to the user.
>>
>>
>> I'm curious as to how this model is different from many existing resource
>> server deployments acting as confidential clients. While the application
>> code is running in the browser, only the access token is exposed to the
>> browser as is the case for many RS deployments where the RS returns the
>> access token to the browser after the authorization flow completes. My
>> interpretation of "confidential client" does not include whether the
>> client's code is "visible" to externals or not, but rather whether the
>> client can protect the secret.
>>
>> In that sense I don't believe this deployment model is "effectively a
>> public client". A hybrid model description is fine, and I don't disagree
>> that some authorization servers may want to treat these clients in a
>> different way.
>>
>> Thanks,
>> George
>>
> --
> 
> Aaron Parecki
> aaronparecki.com
> @aaronpk 
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Pedro Igor Silva]

Nice work Vittorio.

I think the "sub" claim can also be used to reference the client (depending
on the implementation may not necessarily map to the client_id). It might
eventually reference the same entity as the client_id.

In addition to the "sub" claim, does it make sense to explicitly have
the "preferred_username"
claim (section 5.1 of OpenID.Core) as OPTIONAL in Section 2.2 Data Structure
? Isn't this claim a quite common piece of information processed by
resource servers?

Regards.
Pedro Igor

On Mon, Mar 25, 2019 at 2:59 PM Hans Zandbelt 
wrote:

> Without agreeing or disagreeing: OIDC does not apply here since it is not
> OAuth and an access token is not an id_token.
> The JWT spec says in https://tools.ietf.org/html/rfc7519#section-4.1.2:
>
> "The "sub" (subject) claim identifies the principal that is the
>subject of the JWT.  The claims in a JWT are normally statements
>about the subject.  The subject value MUST either be scoped to be
>locally unique in the context of the issuer or be globally unique.
>The processing of this claim is generally application specific"
>
> which kind of spells "client" in case of the client credentials grant but
> I also do worry about Resource Servers thinking/acting only in terms of
> users
>
> Hans.
>
> On Mon, Mar 25, 2019 at 2:41 PM Dominick Baier 
> wrote:
>
>> IMHO the sub claim should always refer to the user - and nothing else.
>>
>> OIDC says:
>>
>> "Subject - Identifier for the End-User at the Issuer."
>>
>> client_id should be used to identify clients.
>>
>> cheers
>> Dominick
>>
>> On 25.. March 2019 at 05:13:03, Nov Matake (mat...@gmail.com) wrote:
>>
>> Hi Vittorio,
>>
>> Thanks for the good starting point of standardizing JWT-ized AT.
>>
>> One feedback.
>> The “sub” claim can include 2 types of identifier, end-user and client,
>> in this spec.
>> It requires those 2 types of identifiers to be unique each other in the
>> IdP context.
>>
>> I prefer omitting “sub” claim in 2-legged context, so that no such
>> constraint needed.
>>
>> thanks
>>
>> nov
>>
>> On Mar 25, 2019, at 8:29, Vittorio Bertocci <
>> vittorio.bertocci=40auth0@dmarc.ietf.org> 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
>>
>> 
>>) - 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 next update.
>>- On my flight back I did my best to incorporate all the ideas and
>>feedback in a draft, which will be discussed at IETF104 tomorrow. Rifaat,
>>Hannes and above all Brian were all super helpful in negotiating the
>>mysterious syntax of the RFC format and submission process.
>>
>> I was blown away by the availability, involvement and willingness to
>> invest time to get things right that everyone demonstrated in the process.
>> This is an amazing community.
>> V.
>> 

Re: [OAUTH-WG] redircet_uri matching algorithm

[Pedro Igor Silva]

- Original Message -
> From: "Antonio Sanso" 
> To: "John Bradley" 
> Cc: oauth@ietf.org
> Sent: Thursday, May 21, 2015 4:41:28 AM
> Subject: Re: [OAUTH-WG] redircet_uri matching algorithm
> 
> 
> On May 21, 2015, at 4:35 AM, John Bradley  wrote:
> 
> > I think the correct answer is that clients should always assume exact
> > redirect_uri matching, and servers should always enforce it.
> > 
> > Anything else is asking for trouble.
> 
> FWIW I completely agree with John here…
> 
> regards
> 
> antonio

+1

> 
> 
> > 
> > If clients need to maintain some state the correct thing to do is use the
> > state parameter, and not append extra path or query elements to there
> > redirect_uri.
> > 
> > A significant number of security problems in the wild come from servers not
> > enforcing this.
> > 
> > I may be taking an excessively hard line, but partial matching is not
> > something we should be encouraging by making easier.
> > 
> > I did do a draft on a way to safely use state
> > https://tools.ietf.org/id/draft-bradley-oauth-jwt-encoded-state-04.txt
> > 
> > John B.
> > 
> > 
> >> On May 16, 2015, at 4:43 AM, Patrick Gansterer  wrote:
> >> 
> >> "OAuth 2.0 Dynamic Client Registration Protocol” [1] is nearly finished
> >> and provides the possibility to register additional “Client Metadata”.
> >> 
> >> OAuth 2.0 does not define any matching algorithm for the redirect_uris.
> >> The latest information on that topic I could find is [1], which is 5
> >> years old. Is there any more recent discussion about it?
> >> 
> >> I’d suggest to add an OPTIONAL “redirect_uris_matching_method” client
> >> metadata. Possible valid values could be:
> >> * “exact”: The “redirect_uri" provided in a redirect-based flow must match
> >> exactly one of of the provided strings in the “redirect_uris” array.
> >> * “prefix”: The "redirect_uri" must begin with one of the “redirect_uris”.
> >> (e.g. "http://example.com/path/subpath” would be valid with
> >> [“http://example.com/path/“, “http://example.com/otherpath/”])
> >> * “regex”: The provided “redirect_uris” are threatened as regular
> >> expressions, which the “redirect_uri” will be matched against. (e.g.
> >> “http://subdomain.example.com/path5/“ would be valid with
> >> [“^http:\\/\\/[a-z]+\\.example\\.com\\/path\\d+\\/“]
> >> 
> >> If not defined the server can choose any supported method, so we do not
> >> break existing implementations. On the other side it allows an client to
> >> make sure that a server supports a specific matching algorithm required
> >> by the client. ATM a client has no possibility to know how a server
> >> handles the redirect_uris.
> >> 
> >> [1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-29
> >> [2] http://www.ietf.org/mail-archive/web/oauth/current/msg02617.html
> >> 
> >> --
> >> Patrick Gansterer
> >> 
> >> ___
> >> OAuth mailing list
> >> OAuth@ietf.org
> >> https://www.ietf.org/mailman/listinfo/oauth
> > 
> > ___
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> 

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

Re: [OAUTH-WG] Token Chaining Use Case

[Pedro Igor Silva]

Hey Donald,

I see your point. And yes, they are no really different.

However, I think this is pretty much about refreshing tokens. I understand that 
in this case the refresh token is not presented by its owner but someone 
downstream. But you are kind of refreshing a previously issued token. And maybe 
using a specific grant_type when refreshing can help to handle this case 
differently considering all its particularities.

Regards.
Pedro Igor

- Original Message -
> From: "Donald F. Coffin" 
> To: "Pedro Igor Silva" , "Bill Mills" 
> 
> Cc: "Phil Hunt" , oauth@ietf.org
> Sent: Thursday, March 26, 2015 6:29:41 PM
> Subject: RE: [OAUTH-WG] Token Chaining Use Case
> 
> Pedro,
> 
> Although the registry could be changed to support the new type format, how is
> that any different than adding a new grant_type, such as
> grant_type=token_swap or grant_type=swap?
> 
> Best regards,
> Don
> Donald F. Coffin
> Founder/CTO
> 
> REMI Networks
> 2335 Dunwoody Crossing Suite E
> Dunwoody, GA 30338-8221
> 
> Phone:      (949) 636-8571
> Email:   donald.cof...@reminetworks.com
> 
> -Original Message-
> From: Pedro Igor Silva [mailto:psi...@redhat.com]
> Sent: Thursday, March 26, 2015 5:25 PM
> To: Bill Mills
> Cc: Donald F. Coffin; Phil Hunt; oauth@ietf.org
> Subject: Re: [OAUTH-WG] Token Chaining Use Case
> 
> Couldn't be used a specific type of refresh_token ? Instead of using
> grant_type=refresh_token use a
> grant_type=urn:ietf:params:oauth:grant_type:redelegate (or something else)
> as an extension to refresh token flow ?
> 
> Regards.
> Pedro Igor
> 
> - Original Message -
> > From: "Bill Mills" 
> > To: "Donald F. Coffin" , "Phil Hunt"
> > 
> > Cc: oauth@ietf.org
> > Sent: Thursday, March 26, 2015 6:13:05 PM
> > Subject: Re: [OAUTH-WG] Token Chaining Use Case
> > 
> > The RS calling back to the AS won't be confused, the token it gets
> > would be it's refresh token. I don't see any reason why the AS can't
> > be smart enough to know that a token that looks like an access token
> > it issued is usable as a refresh token for limited purposes or downscoping.
> > 
> > 
> > 
> > On Thursday, March 26, 2015 1:46 PM, Donald F. Coffin
> >  wrote:
> > 
> > 
> > -1
> > Although Justin’s point might be a bit pre-mature as far as a
> > standards discussion, the more critical reason IMHO is calling the
> > AS’s /Token endpoint with a grant_type of “refresh_token” but
> > providing an issued AT rather than an issued refresh_token (RT) will
> > definitely create a backwards compatibility issue for many implementations.
> > Best regards,
> > Don
> > Donald F. Coffin
> > Founder/CTO
> > REMI Networks
> > 2335 Dunwoody Crossing Suite E
> > Dunwoody, GA 30338-8221
> > Phone: (949) 636-8571
> > Email: donald.cof...@reminetworks.com
> > From: Phil Hunt [mailto:phil.h...@oracle.com]
> > Sent: Thursday, March 26, 2015 4:22 PM
> > To: Bill Mills
> > Cc: 
> > Subject: Re: [OAUTH-WG] Token Chaining Use Case
> > +1. We all have to change production code when non final specs evolve.
> > I particularly don't see this as a valid argument at the start of a
> > standards discussion.
> > 
> > Phil
> > 
> > On Mar 26, 2015, at 15:13, Bill Mills < wmills_92...@yahoo.com > wrote:
> > 
> > 
> > 
> > By definition an access token is becoming a form of refresh token. The
> > "because my implementation didn't do it that way" isn't convincing me.
> > On Thursday, March 26, 2015 12:44 PM, Justin Richer < jric...@mit.edu
> > >
> > wrote:
> > Because many implementations (including mine which does support my old
> > token chaining draft) treat access tokens and refresh tokens
> > separately in terms of data store and structure. Additionally, the
> > refresh token is tied to the client and presented by the client. But
> > in this case it's someone downstream, an RS, presenting the token. So
> > unlike a refresh token being presented by the one it was issued to,
> > this token is being presented by someone it was presented to.
> > The feeling is close, but not quite the same in either development or
> > assumptions.
> > -- Justin
> > / Sent from my phone /
> > 
> > 
> >  Original message 
> > From: Bill Mills < wmills_92...@yahoo.com >
> > Date: 03/26/2015 2:24 PM (GMT-06:00)
> > To: Justin Richer < jric...@mit.edu >, "< oau

Re: [OAUTH-WG] Token Chaining Use Case

[Pedro Igor Silva]

Couldn't be used a specific type of refresh_token ? Instead of using 
grant_type=refresh_token use a 
grant_type=urn:ietf:params:oauth:grant_type:redelegate (or something else) as 
an extension to refresh token flow ?

Regards.
Pedro Igor

- Original Message -
> From: "Bill Mills" 
> To: "Donald F. Coffin" , "Phil Hunt" 
> 
> Cc: oauth@ietf.org
> Sent: Thursday, March 26, 2015 6:13:05 PM
> Subject: Re: [OAUTH-WG] Token Chaining Use Case
> 
> The RS calling back to the AS won't be confused, the token it gets would be
> it's refresh token. I don't see any reason why the AS can't be smart enough
> to know that a token that looks like an access token it issued is usable as
> a refresh token for limited purposes or downscoping.
> 
> 
> 
> On Thursday, March 26, 2015 1:46 PM, Donald F. Coffin
>  wrote:
> 
> 
> -1
> Although Justin’s point might be a bit pre-mature as far as a standards
> discussion, the more critical reason IMHO is calling the AS’s /Token
> endpoint with a grant_type of “refresh_token” but providing an issued AT
> rather than an issued refresh_token (RT) will definitely create a backwards
> compatibility issue for many implementations.
> Best regards,
> Don
> Donald F. Coffin
> Founder/CTO
> REMI Networks
> 2335 Dunwoody Crossing Suite E
> Dunwoody, GA 30338-8221
> Phone: (949) 636-8571
> Email: donald.cof...@reminetworks.com
> From: Phil Hunt [mailto:phil.h...@oracle.com]
> Sent: Thursday, March 26, 2015 4:22 PM
> To: Bill Mills
> Cc: 
> Subject: Re: [OAUTH-WG] Token Chaining Use Case
> +1. We all have to change production code when non final specs evolve.
> I particularly don't see this as a valid argument at the start of a standards
> discussion.
> 
> Phil
> 
> On Mar 26, 2015, at 15:13, Bill Mills < wmills_92...@yahoo.com > wrote:
> 
> 
> 
> By definition an access token is becoming a form of refresh token. The
> "because my implementation didn't do it that way" isn't convincing me.
> On Thursday, March 26, 2015 12:44 PM, Justin Richer < jric...@mit.edu >
> wrote:
> Because many implementations (including mine which does support my old token
> chaining draft) treat access tokens and refresh tokens separately in terms
> of data store and structure. Additionally, the refresh token is tied to the
> client and presented by the client. But in this case it's someone
> downstream, an RS, presenting the token. So unlike a refresh token being
> presented by the one it was issued to, this token is being presented by
> someone it was presented to.
> The feeling is close, but not quite the same in either development or
> assumptions.
> -- Justin
> / Sent from my phone /
> 
> 
>  Original message 
> From: Bill Mills < wmills_92...@yahoo.com >
> Date: 03/26/2015 2:24 PM (GMT-06:00)
> To: Justin Richer < jric...@mit.edu >, "< oauth@ietf.org >" < oauth@ietf.org
> >
> Subject: Re: [OAUTH-WG] Token Chaining Use Case
> So why can't the access tokne simply be re-used as a refresh token? Why would
> it need a new grant type at all?
> On Thursday, March 26, 2015 11:31 AM, Justin Richer < jric...@mit.edu >
> wrote:
> As requested after last night’s informal meeting, here is the token chaining
> use case that I want to see represented in the token swap draft.
> 
> 
> [ Client ] -> [ A ] -> [ B ] -> [ C ]
> 
> An OAuth client gets an access token AT1, just like it always would, with
> scopes [A, B, C] in order to call service A, which requires all three
> scopes. Service A (an RS) accepts this token since it has its scope, and
> then needs to call service B in turn, which requires scopes [B, C]. It could
> just re-send the token it got in, AT1, but that would give the downstream RS
> the ability to call services with scope [ A ] and it should not be allowed
> to do that. To limit exposure, service A calls a token swap at the AS to
> create AT2 with scopes [ B, C ], effectively acting as an OAuth client
> requesting a downscoped token based on AT1. Service A then acts as an OAuth
> client to call service B, now acting as an RS to service A’s client, and can
> fulfill the request. And it’s turtles all the way down: Service B can also
> call service C, and now B acts as a client, requesting AT3 with scope [ C ]
> based on AT2, and sending AT3 to service C. This prevents C from being able
> to call B or A, both of which would have been available if AT1 had been
> passed around. Note that service A or the Client can also request a
> downscoped token with [ C ] to call service C directly as well, and C
> doesn’t have to care how it got there.
> 
> 
> In other words, it lets the client software be very, very dumb. It doesn’t
> have to do any special processing, doesn’t have to know what’s in the token,
> it just follows the recipe of “I got a token, I get another token based on
> this to call someone else”. It’s also analogous to the refresh token flow,
> but with access tokens going in and out. I’ve deployed this setup several
> times in different service deployments. Even though there is a perform