Frankly I just don't understand. You've even said in your original email, that the oath spec is alive and well in enterprise deployments. And since that is the case, it points to how successful the current state of the RFCs are. So I can't fathom what would make sense to actually change.
If anything it may mean that some people's interpretations of specific words in the documents have been taken to be more specific than intended, however this can't be fixed by changing the words, someone will always interpret them in an inconsistent manner. So, at least from my perspective, there is nothing we need to do, nor should do here as the language is already incredible open and has been successful. That's more than anyone could hope for. If you are interested in continuing down this path anyway, it would be most helpful to focus on one single implementation where the exact wording causes an actual problem in designing that system. And rather than suggesting "we should change the words being used" which feels incredibly arbitrary, please quote the actually source definition and share what is problematic with it. - Warren On Mon, Apr 17, 2023, 16:14 Jaap Francke <Jaap.Francke= 40mendix....@dmarc.ietf.org> wrote: > 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 <oauth-boun...@ietf.org> on behalf of oauth-requ...@ietf.org > <oauth-requ...@ietf.org> > *Date: *Thursday, 2 March 2023 at 20:00 > *To: *oauth@ietf.org <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 <nore...@ietf.org> > To: <a...@ietf.org> > 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 +0000 > From: Jaap Francke <jaap.fran...@mendix.com> > To: "oauth@ietf.org" <oauth@ietf.org> > Subject: [OAUTH-WG] OAuth 2.1 & B2E apps > Message-ID: > < > am0pr06mb418002174bf153ed05d93839e4...@am0pr06mb4180.eurprd06.prod.outlook.com > > > > 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 to understand > and closer to daily practice. > > The main changes I?m proposing for section 1 are the following. Changes in > the rest of the draft RFC follow naturally. > > > 1. In the introduction I would add: ?A different example is: an > employee (enduser) can use an application (client) to access resources that > are under control of his employer (resource owner).? > 2. I would also add: ?Besides delegating user authentication to the > authorization server, the authorization server can arrange for an > authorization decision through a process that involves neither client > application nor service. If the enduser is the resource owner, the > authorization server obtains an authorization grant from the enduser. If a > different entity is the resource owner, the authorization server may make > an authorization decision based on prearranged rules or roles.? > 3. In section 1.1, I would propose to define 5 roles instead of 4. > > OAuth defines five roles: > ?enduser?: > Person that uses a client application to access protected resources on > their behalf. > "resource owner": > An entity capable of granting access to a protected resource. The resource > owner may be the enduser or it may be a different person or it may be an > organization. This is sometimes abbreviated as "RO". > "resource server": > The server hosting the protected resources, capable of accepting and > responding to protected resource requests using access tokens. The resource > server is often accessible via an API. This is sometimes abbreviated as > "RS". > "client": > An application making protected resource requests on behalf of the enduser > and with the resource owner?s authorization. The term "client" does not > imply any particular implementation characteristics (e.g., whether the > application executes on a server, a desktop, or other devices). > "authorization server": > The server issuing access tokens to the client after successfully > authenticating the resource owner and obtaining authorization from the > resource owner or making an authorization decision on behalf of the RO. > This is sometimes abbreviated as "AS". > > > 1. Mostly the term resource owner needs to be replaced with ?enduser? > except when it is about authorization. > 2. In section 1.2, I propose to revise the abstract protocol flow > description to say that it?s the authorization server that somehow > obtains/makes an authorization decision. In the current abstract > description of the OAuth flow it is the client that obtains the > authorization. However in the actual grant flows there is never such > interaction between client and resource owner. Neither in the Authorization > Code flow nor the Client Credential flow. In fact it?s always the AS that > somehow arranges for an authorization decision: in AC flow, the AS may get > consent from the enduser/RO and in the CC flow it is based on a previous > arrangement. I think the following alternate abstraction would have a > better fit with the various grant flows: > > ?1. The client requests authorization from the authorization server. 2. > The authorization server obtains an authorization decision from the > resource owner. This decision can be obtained by interaction with the > resource owner or can 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/> > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://mailarchive.ietf.org/arch/browse/oauth/attachments/20230302/6a18cfb7/attachment.htm > > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: image001.png > Type: image/png > Size: 9766 bytes > Desc: image001.png > URL: < > https://mailarchive.ietf.org/arch/browse/oauth/attachments/20230302/6a18cfb7/attachment.png > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > ------------------------------ > > End of OAuth Digest, Vol 173, Issue 7 > ************************************* > _______________________________________________ > 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
