Hi George, Indeed, it might be time to re-think how scopes work in general.Food for thought for all of us here.
Re: step up auth spec: I suppose you are referring to the "insufficient_user_authentication" error response (in Section 3 <https://www.ietf.org/archive/id/draft-ietf-oauth-step-up-authn-challenge-17.html#name-authentication-requirements-ch>) that might contain suggested scopes? Should such a mechanism be included in the WWW-Authenticate Response (Section 5.1 <https://www.ietf.org/id/draft-jones-oauth-resource-metadata-04.html#name-www-authenticate-response>) in the OPRM draft? This addresses (to some extent) Issue #1 I mentioned in my email (If I have a resource server that has multiple endpoints, each of which require different scopes, how should those be handled?). But it still does not address issue #2 from my previous email: - Does the spec encourage insecure behavior in the caller by requesting tokens with scopes that they do not understand? I.e. If an authorization server is known to provide valuable tokens with certain scopes, can a malicious resource server trick the client into requesting a more powerful token, which it then uses to access some other service? Since the consent dialog is likely to show two trusted names (i.e. the requesting client and the authorization server), the user would be prone to providing consent, even if the scope looks unnecessarily permissive. Thanks, Atul On Tue, Sep 5, 2023 at 6:31 AM George Fletcher < george.fletc...@capitalone.com> wrote: > Hi Atul, > > I think this is the beginning of a really interesting discussion. I'm > wondering if we should start a different thread. The recent OAuth Step-up > spec could help in this regard and static RS documentation could be used to > describe which scopes are needed for which endpoints. However, as we move > authorization to be more fine-grained I'm wondering if "scopes" is really > the right mechanism :) > > Thanks, > George > > On Thu, Aug 31, 2023 at 7:51 PM Atul Tulshibagwale <a...@sgnl.ai> wrote: > >> Hi all, >> I have a couple of questions about the OPRM draft. >> >> >> 1. If I have a resource server that has multiple endpoints, each of >> which require different scopes, how should those be handled? For example, >> in the SSF spec, the SSF Transmitter has a Create Stream endpoint and a >> Polling endpoint. The scopes required for these are different. How would >> the client know which scope is to be used with which endpoint? >> 2. Does the spec encourage insecure behavior in the caller by >> requesting tokens with scopes that they do not understand? I.e. If an >> authorization server is known to provide valuable tokens with certain >> scopes, can a malicious resource server trick the client into requesting a >> more powerful token, which it then uses to access some other service? >> Since >> the consent dialog is likely to show two trusted names (i.e. the >> requesting >> client and the authorization server), the user would be prone to providing >> consent, even if the scope looks unnecessarily permissive. >> >> Thanks, >> Atul >> >> >> On Mon, Aug 28, 2023 at 2:28 AM Takahiko Kawasaki <t...@authlete.com> >> wrote: >> >>> I support adoption. >>> >>> In the past, when considering the encryption of JWT access tokens, I >>> learned that the draft regarding the metadata of the resource server had >>> expired, which was disappointing. For an authorization server to encrypt an >>> access token with an asymmetric algorithm, it must obtain a public key of >>> the target resource server, but there was no standardized way. I'm glad to >>> see the specification has been revived. If it had been revived a bit >>> earlier, the addition that was made as "client" metadata in the "JWT >>> Response for OAuth Token Introspection" specification would likely have >>> been treated as metadata for the "resource server." >>> >>> Best Regards, >>> Takahiko Kawasaki >>> >>> >>> On Thu, Aug 24, 2023 at 4:02 AM Rifaat Shekh-Yusef < >>> rifaat.s.i...@gmail.com> wrote: >>> >>>> All, >>>> >>>> This is an official call for adoption for the *Protected Resource >>>> Metadata* draft: >>>> https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/ >>>> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/__;!!FrPt2g6CO4Wadw!N8gLoeZlw-VqqII-5NyTdODjNh5xOu5FltznTR8h7b9x28Vo_CRPCGsPIRwdQcPIe6A7I0iUpAbb0gouoGdW$> >>>> >>>> Please, reply on the mailing list and let us know if you are in favor >>>> of adopting this draft as WG document, by *Sep 6th.* >>>> >>>> Regards, >>>> Rifaat & Hannes >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/oauth__;!!FrPt2g6CO4Wadw!N8gLoeZlw-VqqII-5NyTdODjNh5xOu5FltznTR8h7b9x28Vo_CRPCGsPIRwdQcPIe6A7I0iUpAbb0vbvkqcw$> >>>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/oauth__;!!FrPt2g6CO4Wadw!N8gLoeZlw-VqqII-5NyTdODjNh5xOu5FltznTR8h7b9x28Vo_CRPCGsPIRwdQcPIe6A7I0iUpAbb0vbvkqcw$> >>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/oauth__;!!FrPt2g6CO4Wadw!N8gLoeZlw-VqqII-5NyTdODjNh5xOu5FltznTR8h7b9x28Vo_CRPCGsPIRwdQcPIe6A7I0iUpAbb0vbvkqcw$ >> > ------------------------------ > > The information contained in this e-mail is confidential and/or > proprietary to Capital One and/or its affiliates and may only be used > solely in performance of work or services for Capital One. The information > transmitted herewith is intended only for use by the individual or entity > to which it is addressed. If the reader of this message is not the intended > recipient, you are hereby notified that any review, retransmission, > dissemination, distribution, copying or other use of, or taking of any > action in reliance upon this information is strictly prohibited. If you > have received this communication in error, please contact the sender and > delete the material from your computer. > > > > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
