Re: [OAUTH-WG] OAuth 2.1 & B2E apps (Jaap Francke)

[Jaap Francke]

Hi all,

Early March I shared the suggestion to make the abstract OAuth protocol 
description a bit more generic so it would not only have a fit with B2C use 
cases but would suit B2E use cases as well.
I haven’t seen any response from you – I find myself wondering why.
As my suggestion still makes sense to me, I’d appreciate a response.
Thanks in advance!

Cheers, Jaap

From: OAuth  on behalf of oauth-requ...@ietf.org 

Date: Thursday, 2 March 2023 at 20:00
To: oauth@ietf.org 
Subject: OAuth Digest, Vol 173, Issue 7
Send OAuth mailing list submissions to
oauth@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
https://www.ietf.org/mailman/listinfo/oauth
or, via email, send a message with subject or body 'help' to
oauth-requ...@ietf.org

You can reach the person managing the list at
oauth-ow...@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of OAuth digest..."


Today's Topics:

   1. Artart last call review of
  draft-ietf-oauth-step-up-authn-challenge-12
  (Robert Sparks via Datatracker)
   2. OAuth 2.1 & B2E apps (Jaap Francke)


--

Message: 1
Date: Thu, 02 Mar 2023 10:41:34 -0800
From: Robert Sparks via Datatracker 
To: 
Cc: draft-ietf-oauth-step-up-authn-challenge@ietf.org,
last-c...@ietf.org,  oauth@ietf.org
Subject: [OAUTH-WG] Artart last call review of
draft-ietf-oauth-step-up-authn-challenge-12
Message-ID: <167778249416.23678.7058306125542432...@ietfa.amsl.com>
Content-Type: text/plain; charset="utf-8"

Reviewer: Robert Sparks
Review result: Ready with Issues

Summary: essentially ready but with issues to consider before being published
as a proposed standard RFC.

Issues:

I expected to find some discussion of considerations of avoiding "step down"
given the intuitive appeal to "step up". Can the client or Authorization server
notice if the resource server has through whatever fault asserted that it will
only accept the use of an authentication context class that is blatantly
inferior to what has already been provided? And if they notice, what is
expected to happen? Or is it expected that this is allowed, particularly when a
short max_age is also supplied?

The document also suggests that the client hold on to, and possibly re-use in
the future, access tokens that have been challenged as having insufficient user
authorization. Is this behavior something that follows a well-known and
well-implemented pattern documented elsewhere? If so, a pointer would be
useful. If not, this seems like something that deserves more discussion if not
more definition.

Nits:
The reference to abr-twitter-reply will go away with the changelog when the RFC
Editor removes it. It would be kind to acknowledge that in the note to the RFC
Editor so that they know it's expected and don't have to ask.





----------

Message: 2
Date: Thu, 2 Mar 2023 18:59:26 +
From: Jaap Francke 
To: "oauth@ietf.org" 
Subject: [OAUTH-WG] OAuth 2.1 & B2E apps
Message-ID:



Content-Type: text/plain; charset="windows-1252"

Hi all,

I?d like to pitch the idea of changing the abstract OAuth description to 
incorporate  how OAuth is used in many B2E applications.
In my view, OAuth 2.1 is a great opportunity to do so, without the need to make 
any changes in the core protocol itself, so nothing gets ?broken?.
The 2.1 RFC would be just acknowledging how OAuth is already used widely today.

To the best of my understanding, OAuth (as per RFC6749) originated from a 
Business-to-Consumer (B2C) context.
The typical example that is frequently used to explain OAuth is about an 
enduser (resource owner) that can grant a printing service (client) access to 
their protected photos stored at a photo sharing service (resource server).
What I see in everyday practice in the IAM field, is that OAuth is used for 
Business-to-employee (B2E) applications (often in combination with the OIDC 
extension).
In this context, the enduser is not the resource owner. Instead, the company is 
owning the resources stored at its resource servers and employees (or other 
type of endusers) are granted access  based on roles/rules implemented at the 
resource server.
One may say that OAuth was not designed for such B2E scenarios, but I would say 
that the protocol is perfectly suitable. Practice proves this.
I don?t have hard data to further prove my point but I expect OAuth is 
worldwide being used more often for B2E like applications than it is for B2C 
applications.

The good news is that the narrative around the core specs can be re-written to 
make it more generally applicable without changing the protocol itself.
I think this will be beneficial to anyone working with OAuth, newbies or 
experienced IAM workforce. In my view things will be easier

[OAUTH-WG] OAuth 2.1 & B2E apps

[Jaap Francke]

 be 
made made using logic that was pre-arrenged with the resource owner. 3. The 
client receives […etc…]”

Furthermore, I think that my proposal opens up OAuth for more scenarios, such 
as one consumer may granting another consumer access to its resources 
(UMA-like) and the AS would have a match with the concept of a Policy Decision 
Point (as per XACML specs).

I’m very curious to see your feedback on my proposal.
Do you agree with my point of generalizing beyond B2C?
Do you agree that Oauth 2.1 is the right opportunity to generalize OAuth from 
B2C to a wider set of scenarios?

Kind regards,

Jaap Francke
Product Manager IAM
+31(0)641495324
mendix.com
[signature_827714327]<http://www.mendix.com/>


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

Re: [OAUTH-WG] Tenancy in OAuth

[Jaap Francke]

Thanks Justin and Vladimir for your guidance!

The resource indicator approach seems to have the best fit for my use case.
It addresses my coarse/mid-grained use case, without bringing the complexity of 
the fine-grained RAR approach.
Encoding the tenant into scope values remains an option as well.
Ensuring the token validation is implemented properly is indeed a point of 
attention.

Meanwhile I've been looking into OAuth/OIDC specs for client registration. 
It may also be useful to extend the client's metadata with 'resource' to bind 
the specific client to a specific tenant(s).
Would that make sense to you as well?

Great feedback, kind regards, 
Jaap


On 12/01/2021, 23:10, "OAuth on behalf of oauth-requ...@ietf.org" 
 wrote:

Send OAuth mailing list submissions to
oauth@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit

https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cjaap.francke%40mendix.com%7C93707202bd484789530008d8b746e1f4%7Cb4e3c78d8e3b46d8bc565540da23ba4d%7C0%7C0%7C637460862383168168%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zNVyuy2avEEWtIJ3eXZGEV9S0KLyYj27KiG2yOPtW9Q%3D&reserved=0
or, via email, send a message with subject or body 'help' to
oauth-requ...@ietf.org

You can reach the person managing the list at
oauth-ow...@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of OAuth digest..."


Today's Topics:

   1. Re: Tenancy in OAuth (Justin Richer)
   2. Re: Tenancy in OAuth (Vladimir Dzhuvinov)


--

Message: 1
Date: Tue, 12 Jan 2021 16:13:26 -0500
From: Justin Richer 
To: Jaap Francke 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Tenancy in OAuth
Message-ID: 
Content-Type: text/plain; charset="utf-8"

Hi Jaap,

There have been a number of efforts to address this kind of thing in the 
OAuth world. You can definitely use a special scope to encode this value, which 
has the benefit of fitting into the implementation limitations of nearly all 
OAuth systems out there. The ?resource? parameter can also be used for the kind 
of thing, and it gives you a bucket that?s separate from ?scope? so that you 
can keep the latter available for describing the API itself:


https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8707&data=04%7C01%7Cjaap.francke%40mendix.com%7C93707202bd484789530008d8b746e1f4%7Cb4e3c78d8e3b46d8bc565540da23ba4d%7C0%7C0%7C637460862383168168%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=5clKn%2B8%2FCEiQindejfHncA670FWVoy%2BHDQ49JtOORjE%3D&reserved=0
 
<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8707&data=04%7C01%7Cjaap.francke%40mendix.com%7C93707202bd484789530008d8b746e1f4%7Cb4e3c78d8e3b46d8bc565540da23ba4d%7C0%7C0%7C637460862383168168%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=5clKn%2B8%2FCEiQindejfHncA670FWVoy%2BHDQ49JtOORjE%3D&reserved=0>

There?s also the Rich Authorization Request (RAR) draft that this group is 
currently working on, which provides a multi-dimensional way to describe 
access. It?s more complex than scopes, but it boils down to having JSON objects 
describe the elements needed. In this case you might put the API bits into the 
?actions? and ?datatypes? fields, and put the tenant information into the 
?locations? field. I believe there are people using it in exactly this way 
today:


https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-oauth-rar-03&data=04%7C01%7Cjaap.francke%40mendix.com%7C93707202bd484789530008d8b746e1f4%7Cb4e3c78d8e3b46d8bc565540da23ba4d%7C0%7C0%7C637460862383168168%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=hxn2gFdUhhmWrf0ATaqUUUB9C62yh%2FY27aNOvR1hWbM%3D&reserved=0
 
<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-oauth-rar-03&data=04%7C01%7Cjaap.francke%40mendix.com%7C93707202bd484789530008d8b746e1f4%7Cb4e3c78d8e3b46d8bc565540da23ba4d%7C0%7C0%7C637460862383168168%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=hxn2gFdUhhmWrf0ATaqUUUB9C62yh%2FY27aNOvR1hWbM%3D&reserved=0>

There are also some historical efforts to address this, including an 
?audience? and a (completely separate) ?aud" parameter, but AFAIK neither of 
these have been raised to standard or even to common

[OAUTH-WG] Tenancy in OAuth

[Jaap Francke]

Hi,

I’m looking into the topic of tenancy. A multi-tenant service can be considered 
as an OAuth Resource Server managing resources of different tenants.
An AS makes authorization decisions and communicates these using scopes, so one 
way would be to ‘encode’ the tenant into the scope values.
Another line of thought is to somehow bind/restrict an acces-token to a certain 
tenant, leaving the set of scopes being used more static.

My question is whether this has been a topic that has been addressed in the 
OAuth working group? Any common practice or draft?
Thanks in advance for your replies.

Kind regards,

Jaap Francke
Product Manager Identity
+31(0)641495324
mendix.com
[signature_827714327]<http://www.mendix.com/>


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

[OAUTH-WG] FW: Confirm email address

[Jaap Francke]

Confirming my email address.
Somehow I seem to have used wrong email address before?

Kind regards, Jaap

From: Jaap Francke 
Date: Monday, 21 December 2020 at 16:44
To: "oa...@ietfa.amsl.com" 
Subject: Confirm email address

I just subscribed today and already confirmed my email address.
But doing it again to be sure.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Confirm email address

[Jaap Francke]

I just subscribed today and already confirmed my email address.
But doing it again to be sure.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwt-introspection-response-08

[Jaap Francke]

Hi Ben,

I saw your question and by coincidence i had just been doing some reading in 
RFC7662.
Maybe this helps.

Could you give me a pointer where in the text it says that if "active" is
false, no other claims are present?  ("active" only appears three times,
but none of them seem to say this.)

https://tools.ietf.org/html/rfc7662#page-12 says:


   To avoid disclosing the internal state of the authorization server,
   an introspection response for an inactive token SHOULD NOT contain
   any additional claims beyond the required "active" claim (with its
   value set to "false”).



Regards, jaap Francke

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

[OAUTH-WG] client authentication

[Jaap Francke]

Hi all,

I was exploring the topic of client authentication in various RFCs.
A few things are not 100% clear to me, I would be interested to get your 
feedback.

RFC7591 sets up the registry for client authentication methods on the token 
endpoint and adds:
- none
- client_secret_basic (RFC2617)
- client_secret_post (RFC6749)

I don’t understand why that registry seems limited to the token-endpoint. 
Client authentication also applies to other protected (OAuth) endpoints such as 
token introspect, so it makes sense to have a generic (OAuth) client 
authentication method registry.

OIDC specs indicate a few more:
- client_secret_jwt
- private_key_jwt
Is my understanding correct that client_secret_jwt refers to the same client 
authentication method as described in 
https://tools.ietf.org/html/rfc7523#section-2.2 ?

Furthermore there is RFC6750 which suggest 3 client authentication mechanisms 
which are not included in the registry:
- Bearer / authorisation request header
- bearer / URI query parameter
- bearer / form encoded body parameter
For example, the RFC7662 suggests to use the “bearer / authorisation request 
header” mechanism as client authentication/authorisation mechanism.
Any reason why this was not done?

Thanks in advance for any related feedback, regards,

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

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

[Jaap Francke]

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 authorisation is conceptually broken down into:
- subject -> requesting party
- verbs -> scopes of access
- object -> resource set.
I like this line of thinking and terminilogy.  However, if access_tokens are 
bearer tokens, I think ’subject’ is the bearer of the token.


The most common practice, I think, is to use OIDC’s IDTokens to contain a set 
of claims that scope the scope of the scope :-).

I mean that the claims in the ID-Tokens are used to scope the objects as well 
as the verbs/scopes of access.

The core intention behind ID-token is to provide information about the 
authenticated user and not necessarily about the resources that are accessed. 
In practice, claims about the authenticated users indicate which resources 
(photos) can be accessed at the resource server.


My understanding of this draft 
https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-02

is that the object/resource aspect of authorisation is taken somewhat out of 
the scope and put into a dedicated parameter. Although (using the example from 
RFC 6749) the resource parameter indicates the resource server (or application,

   API, etc.) rather than an individual resource that is stored at the resource 
server. So additional scoping of object/resource set is still needed in 
addition to the resource parameter.


Furthermore, https://tools.ietf.org/html/draft-ietf-oauth-security-topics-12 
makes some interesting statements that are relevant in my view:
The section on Access Token privilege restriction says "access tokens SHOULD be 
restricted to certain resources

   and actions on resource servers or resources.” So the OAuth scope-string 
still needs to somehow indicate the resource-scope of the privilege that is 
communicated.


" The client needs to tell the authorization server, at which URL it

   will use the access token it is requesting.  It could use the
   mechanism proposed 
[I-D.ietf-oauth-resource-indicators]
 or encode the
   information in the scope value.”


I’m not sure which point I’m trying to make; i guess the need for 
standardisation how to use and define OAuth-scopes.

I like the Lodging Intent Pattern and need to do some more reading/thinking 
about the structured-scope and pushed request objects.

I feel these concepts are not only relevant for authorisation of transactions, 
but also for any access that needs authorisation.


I’m not sure if i express myself clearly, nevertheless any feedback is welcome, 
if not alone to get my understanding of the various concepts on a higher level.


Thanks in advance, kind regards


Jaap







Message: 1
Date: Wed, 24 Apr 2019 19:08:25 +0200
From: Torsten Lodderstedt 
mailto:tors...@lodderstedt.net>>
To: Sascha Preibisch 
mailto:saschapreibi...@gmail.com>>
Cc: oauth mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] Transaction Authorization with OAuth
Message-ID: 
<2997b550-c82b-4d3a-9639-15a004f2f...@lodderstedt.net

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

[Jaap Francke]

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<mailto:oauth-requ...@ietf.org> 
wrote:

   draft-ietf-oauth-resource-indicators-02

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

Re: [OAUTH-WG] WGLC for OAuth 2.0 Device Flow for Browserless and Input Constrained Devices (Brian Campbell)

[Jaap Francke]

Hi all,

I have previously made the following suggestion which still makes sense to me.

[…]we were working with one of our customers to implement the device flow as 
part of our IDaaS.
One of the requirements was the ability to revoke tokens for one of the devices 
at the Resource Server.

In our use case, we used the terminolgy ‘pairing a device to the enduser’s 
account’ to describe the process of authorising a device to access the resource 
owner’s resources.
The resource owner may want to ‘unpair’ a device from a list of paired devices 
without having access to the device itself (anymore). Think about a stolen/lost 
kind of situation.
We are looking for ways to allow the user to unpair one of his devices at the 
Authorisation Server.
Since the Device Flow exchanges only the ‘generic’ client_id with the 
Authorisation Server, there is no logical way at the Resource Server to make a 
distinction between various devices (having the same client_id) that may be 
paired to the same Resource Owner.

My suggestion is the following
- add an optional parameter to the device authorisation request (or device 
access token request): 'device_identifier'. A device can use this to make (for 
example) its serial-number known at the Resource Server.
- add an optional parameter to the device access token response that allows to 
communicate a name for the device as may have been given to it by the resource 
owner while allowing the clients access (E). This parameter could be something 
like ‘device_name’. The device may be able to display this ‘device_name’ on its 
display.

Please consider this as a suggested enhancement of the Device Flow 
specifications.


Kind regards,

Jaap
> On 11 Dec 2017, at 18:56, oauth-requ...@ietf.org wrote:
> 
> Send OAuth mailing list submissions to
>   oauth@ietf.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>   https://www.ietf.org/mailman/listinfo/oauth
> or, via email, send a message with subject or body 'help' to
>   oauth-requ...@ietf.org
> 
> You can reach the person managing the list at
>   oauth-ow...@ietf.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of OAuth digest..."
> 
> 
> Today's Topics:
> 
>   1. Re: WGLC for OAuth 2.0 Device Flow for Browserless and Input
>  Constrained Devices (Brian Campbell)
>   2. Re: I-D Action: draft-ietf-oauth-token-exchange-10.txt
>  (Justin Richer)
> 
> 
> --
> 
> Message: 1
> Date: Mon, 11 Dec 2017 09:46:09 -0700
> From: Brian Campbell 
> To: Rifaat Shekh-Yusef 
> Cc: oauth 
> Subject: Re: [OAUTH-WG] WGLC for OAuth 2.0 Device Flow for Browserless
>   and Input Constrained Devices
> Message-ID:
>   
> Content-Type: text/plain; charset="utf-8"
> 
> I couldn't get the QR code to work... ;)
> 
> On Mon, Nov 27, 2017 at 6:55 AM, Rifaat Shekh-Yusef 
> wrote:
> 
>> All,
>> 
>> As discussed in Singapore, we are starting a WGLC for the
>> *draft-ietf-oauth-device-flow-07* document, starting today and ending on
>> December 11, 2018.
>> https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/
>> 
>> Please, review the document and provide feedback on the list.
>> 
>> 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.*
> -- next part --
> An HTML attachment was scrubbed...
> URL: 
> 
> 
> --
> 
> Message: 2
> Date: Mon, 11 Dec 2017 12:56:21 -0500
> From: Justin Richer 
> To: Brian Campbell 
> Cc: Denis , "" 
> Subject: Re: [OAUTH-WG] I-D Action:
>   draft-ietf-oauth-token-exchange-10.txt
> Message-ID: <94aa427c-744b-4a33-aefc-a5f276c91...@mit.edu>
> Content-Type: text/plain; charset="utf-8"
> 
> +1 to Brian
> 
> -1 to the proposed text from Denis
> 
> 
>> On Dec 8, 2017, at 8:48 PM, Brian Campbell  
>> wrote:
>> 
>> The privacy matter is already mentioned. Despite your many messages to this 
>> WG and others about the so called ABC attack, I do not believe it warrants 
>> treatment in this document or others. And your continued proposals to have 
>> it included in documents have not gotten support.  
>> 
>> On Fri, Dec 8, 2017 at 2:46 PM, Denis > > wrote:
>> RFC 3552 (Guidelines for Writing RFC Text on Security Considerations) 
>> states: 
>> 
>>   All RFCs are required by RF

[OAUTH-WG] Using OAuth for password reset

[Jaap Francke]

Hi all,

I was wondering if anyone considered using OAuth for password resets. Or maybe 
this is common practice, I don’t know.

My line of thinking is that a password is "just-another-resource" that is 
stored at a resource server.
So the resource server requires an access token for anyone/any client that 
wants to update/change the password.
The authorisation server that issues access-tokens somehow needs to 
authenticate the client that wants an access token for changing a certain 
password.

Authentication is half in-scope and half out-of-scope of OAuth specifications.
In the Authorisation Code grant (AC), it is left out-of-scope how the AS 
authenticates the RO, but it does state it should happen through the user-agent 
during the execution of the grant.
In the ResourceOwner password credential (ROPC) grant, the username/password is 
sent to the AS as part of the authorisation request / redirect.

For a password reset scenario, I would say we need a new grant which would be 
inbetween AC-grant and ROPC-grant:
- it starts with a redirect to the AS including a “password reset token” - 
somewhat similar to the ROPC-grant: the password reset-token can be viewed as 
combination of username and a (one-time) password. This is basically clicking 
on a password reset link
- subsequently the AS could perform additional authentication steps (e.g. 
2FA-SMS) - similar to what is possible with the AC-grant
- when AS thinks the user is sufficiently authenticated, the AS could issue the 
authorisation code and things would proceed as with the AC-grant

Obviously this is preceeded by a request for a password-reset link, which gets 
sent to the legitimate resource owner Out-Of-Bound via email, SMS, or 
whatsoever.

Am I making things too complicated here? Or would this be the proper way to do 
it? I’m trying to hook-up to the most secure OAuth mechanisms.
Any thoughts?

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

Re: [OAUTH-WG] Suggested enhancement of the OAuth Device Flow

[Jaap Francke]

Hi Justin,

Thanks for your reply.

I had missed your proposal, but it’s indeed the same line-of-thought.
My proposal is slightly different in the sense that the device_name (or: 
instance_name) would not originate from the client itself but from the 
ResourceOwner, e.g. during the authorisation process.
This is probably specific or at least more relevant to devices with input 
constraints.

I understand the point about dynamic client registration. 
At a first glance it seems very ‘open’, whereas in a lot of case you wouldn’t 
want any client to register. 
Moreover, I feel that using dynamic client registration just for the sake of 
setting up identifiers for a client instance seems a bit ‘heavy’.
So I still feel it’s usefull to enhance the Device flow with something like: 
device_identifier / device_name / instance_name / instance_description

regards, Jaap


> Message: 2
> Date: Fri, 7 Jul 2017 07:54:13 -0400
> From: Justin Richer 
> To: oauth@ietf.org
> Subject: Re: [OAUTH-WG] Suggested enhancement of the OAuth Device Flow
> Message-ID: <71e43e3c-2bd3-d706-2c82-6020de8ff...@mit.edu>
> Content-Type: text/plain; charset=utf-8; format=flowed
> 
> I proposed this exact thing many years ago:
> 
> https://tools.ietf.org/html/draft-richer-oauth-instance-00
> 
> At the time there wasn't very much interest in it, as people were 
> looking at using Dynamic Registration, with its attendant unique client 
> IDs, to solve that same problem.
> 
>  -- Justin

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

[OAUTH-WG] Suggested enhancement of the OAuth Device Flow

[Jaap Francke]

Hi all,

Recently we were working with one of our customers to implement the device flow 
as part of our IDaaS.
One of the requirements was the ability to revoke tokens for one of the devices 
at the Resource Server.

In our use case, we used the terminolgy ‘pairing a device to the enduser’s 
account’ to describe the process of authorising a device to access the resource 
owner’s resources.
The resource owner may want to ‘unpair’ a device from a list of paired devices 
without having access to the device itself (anymore). Think about a stolen/lost 
kind of situation.
We are looking for ways to allow the user to unpair one of his devices at the 
Authorisation Server.
Since the Device Flow exchanges only the ‘generic’ client_id with the 
Authorisation Server, there is no logical way at the Resource Server to make a 
distinction between various devices (having the same client_id) that may be 
paired to the same Resource Owner.

My suggestion is the following
- add an optional parameter to the device authorisation request (or device 
access token request): 'device_identifier'. A device can use this to make (for 
example) its serial-number known at the Resource Server.
- add an optional parameter to the device access token response that allows to 
communicate a name for the device as may have been given to it by the resource 
owner while allowing the clients access (E). This parameter could be something 
like ‘device_name’. The device may be able to display this ‘device_name’ on its 
display.

Please consider this as a suggested enhancement of the Device Flow 
specifications.

Kind regards,

Jaap Francke
Product Manager, iWelcome



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

[OAUTH-WG] token revocation from a different client

[Jaap Francke]

Hi all,

It’s only since recently that I’m sticking my nose deeper into the various 
OAUTH (draft) specifications.
I also recently joined this mailing list.
I have a question and I hope someone can help me.

I’ve been looking for a mechanism/endpoint/specification for token revocation.

RFC7009 is aimed at token revocation by the client itself - logoff is the 
typical use case.
What I’m looking for is a possibility for the enduser (resource owner) to 
revoke one of his tokens from a different client.

Use cases for this would be:
- suspection that password is compromised, so enduser wants to change his 
password and terminate all sessions on any device. For such devices to regain 
access, they would need the new password.
- stolen/lost device; the enduser should be able to revoke specific 
access/refresh-tokesn that have been issued for the stolen/lost device.

Any thoughts on this? 

Thanks in advance,

Jaap Francke
Product Manager iWelcome

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