Re: [OAUTH-WG] Redefining Confidential and Public Clients
Seems to be similar to the intentions of: https://datatracker.ietf.org/doc/html/rfc8176 and/or https://openid.net/specs/openid-connect-modrna-authentication-1_0-06.html -- -jim Jim Willeke On Wed, Jul 27, 2022 at 7:45 AM Jaimandeep Singh wrote: > Dear Aaron and esteemed members, > > 1. It was good to note that we are planning to simplify the definitions of > confidential and public clients in the new specs. However, my thoughts are > that instead of these definitions which are open to interpretation, we can > work on these two options: > > *Option I*: > 2. We can define the client applications in terms of trust assurance > levels. The trust assurance level will determine the ability of the > application to acquire delegated authorization rights (permitted scopes) > for a longer duration. > > (a) *Trust Assurance Level 0*. This is the minimum trust assurance level. > The application does not have means of mutual identification and > authentication. The delegated authorization rights would be restricted to a > minimum level of permissions (scopes). The lifespan of the delegated > authorization rights (in terms of access and refresh tokens) will be > minimal or for one time use only. > > (b) *Trust Assurance Level 1*. The applications have the means of > establishing mutual identification and authentication. The delegated > authorization rights (scopes) will be more permissive in nature. The > lifespan of the authorization rights (in terms of access and refresh > tokens) will be of a more persistent nature. > > *How Does this help?* > 3. We are moving from the less formal classification and interpretation of > client applications to a more robust definition based on the principles of > mutual identification and authentication. > > 4. It can additionally form the basis of DPoP. > > *Option II:* > 5. In the main meeting we discussed the possibility of moving towards a > uniform OAuth flow by converting public apps to confidential apps. We need > more discussions on the same. > > Regards and Best Wishes > Jaimandeep Singh > > ___ > 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] We appear to still be litigating OAuth, oops
I didn't mean to imply "you" were writing it off and you are probably right
technology may not be able to solve it, I was just looking for ways we
might help?
--
-jim
Jim Willeke
On Wed, Feb 24, 2021 at 10:21 AM Aaron Parecki wrote:
> > Sure, you could write it off as "a business problem" but
>
> I did not mean to suggest that I was *writing it off* as a business
> problem.
>
> It *is* a very real problem, and I would very much like to see a solution,
> however based on my experience it is not something that technology will
> solve. This is demonstrated by the fact that there are all the pieces in
> place already yet many organizations refuse to adopt them, and it’s
> definitely not for a lack of understanding.
>
> Aaron
>
>
>
> On Wed, Feb 24, 2021 at 7:01 AM Jim Willeke wrote:
>
>> But in reality, Just "because the technology" is there there leaves out
>> the practicality of creating a secure implementation. Sure, you could write
>> it off as "a business problem" but many of the developers are small and not
>> unusually single person operations that do not have the resources to create
>> a specific team, or even a specific person, to work through all the
>> specifications that are involved.
>>
>> I do believe, in general, specific implementations should not be within
>> the specifications but a "Best Practices" or "Common Implementations"
>> document to coincide with the specifications might be in order.
>>
>> Just spend some time on https://stackexchange.com/filters/4229/oauth and
>> you will see the issue and struggles.
>>
>>
>> --
>> -jim
>>
>> Jim Willeke
>>
>>
>> On Wed, Feb 24, 2021 at 8:46 AM Aaron Parecki wrote:
>>
>>> > You type your email address into {The Bat} to begin configuration.
>>> {The Bat} does discovery [1][2] to locate the OAuth/OIDC server for {My
>>> ISP}. The discovery document reveals that {My ISP} supports open dynamic
>>> client registration [3][4] so {The Bat} registers and gets issued with a
>>> client id and client secret. {The Bat} then does a normal OAuth flow to get
>>> an access token to access your emails from {My ISP}. If you later stop
>>> using {The Bat} you can go to your page on {My ISP} and revoke its access
>>> because it has a unique client id.
>>>
>>> Like Neil says, the building blocks are all already there. The fact that
>>> companies choose not to use them is not because the technology isn't there,
>>> it's because it's a business problem.
>>>
>>> I'd be thrilled if the NxM problem were solved in practice, but
>>> unfortunately that doesn't seem to be what's happened in the market. The
>>> technical solution has been there a long time, so there's something else
>>> going on.
>>>
>>> When I've brought up this topic in the past, most of the responses I've
>>> gotten from the "big players" are along the lines of "lol we're not going
>>> to let someone's software talk to us unless we have a legal arrangement
>>> with the developer". The fact that dynamic client registration is barely
>>> used is more because these service operators want the software developers
>>> to agree to their terms of service before being able to access APIs.
>>>
>>> This is all to say that I agree it'd be nice to solve this problem, but
>>> in the end, the IETF can't tell companies what to do with their products
>>> and services.
>>>
>>> Aaron
>>>
>>>
>>>
>>>
>>> On Wed, Feb 24, 2021 at 4:21 AM Neil Madden
>>> wrote:
>>>
>>>> On 24 Feb 2021, at 11:39, Bron Gondwana wrote:
>>>>
>>>>
>>>>
>>>> […]
>>>>
>>>>
>>>> Let's get down to use cases then, rather than talking in abstracts.
>>>>
>>>> I'm an end user with a copy of {The Bat email client} and I want to
>>>> connect it to {Gmail} + {Yahoo} + {My ISP}. It supports {POP3}, a widely
>>>> popular open standard. I want to be able to authenticate to each of those
>>>> services without saving my plaintext passwords on my hard disk where the
>>>> next {Windows ME} virus will exfiltrate them to {Noextraditionistan} and
>>>> all my {Dogecoin} will then be exfiltrated from my {Paybuddy} account,
>>>> leaving me destitute.
>>>>
>>>> But, {The Bat} doesn't have a trusted client cert from my isp, because
>>>> who does
Re: [OAUTH-WG] We appear to still be litigating OAuth, oops
But in reality, Just "because the technology" is there there leaves out the
practicality of creating a secure implementation. Sure, you could write it
off as "a business problem" but many of the developers are small and not
unusually single person operations that do not have the resources to create
a specific team, or even a specific person, to work through all the
specifications that are involved.
I do believe, in general, specific implementations should not be within
the specifications but a "Best Practices" or "Common Implementations"
document to coincide with the specifications might be in order.
Just spend some time on https://stackexchange.com/filters/4229/oauth and
you will see the issue and struggles.
--
-jim
Jim Willeke
On Wed, Feb 24, 2021 at 8:46 AM Aaron Parecki wrote:
> > You type your email address into {The Bat} to begin configuration. {The
> Bat} does discovery [1][2] to locate the OAuth/OIDC server for {My ISP}.
> The discovery document reveals that {My ISP} supports open dynamic client
> registration [3][4] so {The Bat} registers and gets issued with a client id
> and client secret. {The Bat} then does a normal OAuth flow to get an access
> token to access your emails from {My ISP}. If you later stop using {The
> Bat} you can go to your page on {My ISP} and revoke its access because it
> has a unique client id.
>
> Like Neil says, the building blocks are all already there. The fact that
> companies choose not to use them is not because the technology isn't there,
> it's because it's a business problem.
>
> I'd be thrilled if the NxM problem were solved in practice, but
> unfortunately that doesn't seem to be what's happened in the market. The
> technical solution has been there a long time, so there's something else
> going on.
>
> When I've brought up this topic in the past, most of the responses I've
> gotten from the "big players" are along the lines of "lol we're not going
> to let someone's software talk to us unless we have a legal arrangement
> with the developer". The fact that dynamic client registration is barely
> used is more because these service operators want the software developers
> to agree to their terms of service before being able to access APIs.
>
> This is all to say that I agree it'd be nice to solve this problem, but in
> the end, the IETF can't tell companies what to do with their products and
> services.
>
> Aaron
>
>
>
>
> On Wed, Feb 24, 2021 at 4:21 AM Neil Madden
> wrote:
>
>> On 24 Feb 2021, at 11:39, Bron Gondwana wrote:
>>
>>
>>
>> […]
>>
>>
>> Let's get down to use cases then, rather than talking in abstracts.
>>
>> I'm an end user with a copy of {The Bat email client} and I want to
>> connect it to {Gmail} + {Yahoo} + {My ISP}. It supports {POP3}, a widely
>> popular open standard. I want to be able to authenticate to each of those
>> services without saving my plaintext passwords on my hard disk where the
>> next {Windows ME} virus will exfiltrate them to {Noextraditionistan} and
>> all my {Dogecoin} will then be exfiltrated from my {Paybuddy} account,
>> leaving me destitute.
>>
>> But, {The Bat} doesn't have a trusted client cert from my isp, because
>> who does - so there's no good protocol for me - it's either plaintext auth,
>> or it's some architecture astronaut multi-party nonsense that's massively
>> over specified and doesn't work half the time. So I write a plain text
>> password on a post-it note which is lying in the dust under my monitor
>> because the glue has gone bad, and I hope I never accidentally click
>> "remember me" when I type it in.
>>
>> That's been the reality of the end user experience for very many years.
>>
>> NxM means that you can authenticate an arbitrary client against an
>> arbitrary server so long as they are both speaking a known public protocol,
>> without needing to build a trust relationship between the client vendor and
>> the server vendor first.
>>
>>
>> Does the following meet your needs?
>>
>> You type your email address into {The Bat} to begin configuration. {The
>> Bat} does discovery [1][2] to locate the OAuth/OIDC server for {My ISP}.
>> The discovery document reveals that {My ISP} supports open dynamic client
>> registration [3][4] so {The Bat} registers and gets issued with a client id
>> and client secret. {The Bat} then does a normal OAuth flow to get an access
>> token to access your emails from {My ISP}. If you later stop using {The
>> Bat} you can go to your page on {My ISP} and revoke its access because it
>> has a unique client id.
>>
>&
Re: [OAUTH-WG] Call for adoption - OAuth 2.1 document
I support addoption -- -jim Jim Willeke On Thu, Jul 16, 2020 at 2:09 AM Dominick Baier wrote: > I support adoption > > ——— > Dominick Baier > > On 16. July 2020 at 01:54:08, William Denniss ( > wdenniss=40google@dmarc.ietf.org) wrote: > > I support adoption. > > On Wed, Jul 15, 2020 at 4:37 PM 40auth0@dmarc.ietf.org> wrote: > >> +1 >> >> >> >> *From:* OAuth *On Behalf Of *Dick Hardt >> *Sent:* Wednesday, July 15, 2020 10:55 AM >> *To:* Rifaat Shekh-Yusef >> *Cc:* oauth >> *Subject:* Re: [OAUTH-WG] Call for adoption - OAuth 2.1 document >> >> >> >> +1 >> >> >> >> On Wed, Jul 15, 2020 at 10:42 AM Rifaat Shekh-Yusef < >> rifaat.s.i...@gmail.com> wrote: >> >> All, >> >> >> >> This is a *call for adoption* for the following *OAuth 2.1* document as >> a WG document: >> >> https://www.ietf.org/id/draft-parecki-oauth-v2-1-03.html >> >> >> >> Please, provide your feedback on the mailing list by *July 29th.* >> >> >> >> Regards, >> >> Rifaat & Hannes >> >> >> >> ___ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> ___ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > ___ > 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] Call for Adoption: DPoP
I support the adoption of DPoP. -- -jim Jim Willeke On Tue, Mar 17, 2020 at 8:21 AM Rifaat Shekh-Yusef wrote: > All, > > As per the conclusion of the PoP interim meeting, this is a call for > adoption for the *OAuth 2.0 Demonstration of Proof-of-Possession at the > Application Layer (DPoP)* document: > https://datatracker.ietf.org/doc/draft-fett-oauth-dpop/ > > Please, let us know if you support or object to the adoption of this > document as a working group document by March 31st. > > Regards, > Rifaat & Hannes > > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Rich Authorization Requests
I support adoption. -- -jim Jim Willeke On Mon, Jan 6, 2020 at 3:36 PM Dick Hardt wrote: > I support adoption > ᐧ > > On Mon, Jan 6, 2020 at 12:32 PM Richard Backman, Annabelle 40amazon@dmarc.ietf.org> wrote: > >> I support adoption. >> >> >> >> – >> >> Annabelle Richard Backman >> >> AWS Identity >> >> >> >> >> >> *From: *OAuth on behalf of John Bradley < >> ve7...@ve7jtb.com> >> *Date: *Monday, January 6, 2020 at 12:05 PM >> *To: *"oauth@ietf.org" >> *Subject: *Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Rich >> Authorization Requests >> >> >> >> I support adoption >> >> On 1/6/2020 4:37 PM, Rifaat Shekh-Yusef wrote: >> >> All, >> >> >> >> This is a call for adoption for the *OAuth 2.0 Rich Authorization >> Requests* document. >> >> https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-rar/ >> >> >> >> Please, let us know if you support or object to the adoption of this >> document as a working group document by Jan 20th. >> >> >> >> Regards, >> >> Rifaat & Hannes >> >> >> >> >> >> ___ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> https://www.ietf.org/mailman/listinfo/oauth >> >> ___ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > ___ > 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] !@s in -security-topics-13
Yes and some are wrong: 3.1.1. Authorization Code Grant AS metadata ([!@RFC8418]) Where RFC8418 is "Use of the Elliptic Curve Diffie-Hellman Key Agreement Algorithm with X25519 and X448 in the Cryptographic Message Syntax (CMS)" and has no Metadata entries. Happy Holiday Jitter? -- -jim Jim Willeke On Mon, Dec 23, 2019 at 5:56 PM Brian Campbell wrote: > There are a few occurrences of [!@RFC...] which presumably come from a > typo in the markdown source for mmark (switching the order of '@' and > '!'). > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.. > If you have received this communication in error, please notify the sender > immediately by e-mail and delete the message and any file attachments from > your computer. Thank you.*___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] MTLS and SAN
I may not be completely up to date in this discussion, However, RFC 6125 <https://tools.ietf.org/html/rfc6125#section-6> "In general, *this specification recommends and prefers* use of subjectAltName entries (DNS-ID, SRV-ID, URI-ID, etc.) over use of the subject field (CN-ID) where possible, as more completely described in the following sections. However, specifications that reuse this one can legitimately encourage continued support for the CN-ID identifier type if they have good reasons to do so, such as backward compatibility with deployed infrastructure (see, for example, [EV-CERTS])." And I believe this is the more common practice. https://security.stackexchange.com/questions/175786/is-it-required-to-have-the-same-domain-name-and-common-name-for-ssl-certificate/175788#175788 -- -jim Jim Willeke On Thu, Apr 4, 2019 at 4:55 PM Filip Skokan wrote: > Yes. > > S pozdravem, > *Filip Skokan* > > > On Thu, 4 Apr 2019 at 22:36, Justin Richer wrote: > >> Thank you, I did miss that text. This should be called out more >> explicitly in §2.1, perhaps by specifying that it is only one field.. This >> still doesn’t set precedence, but it implies that it’s an error for a >> client to have more than one field set of the available options. Is that >> your read on this as well? >> >> — Justin >> >> On Apr 4, 2019, at 4:23 PM, Filip Skokan wrote: >> >> Justin, I had the exact same question off list and believe draft 13 >> clarified this. >> >> https://tools.ietf.org/html/draft-ietf-oauth-mtls-13#section-2.1.2 >> >> A client using the "tls_client_auth" authentication method MUST use >> exactly one of the below metadata parameters to indicate the certificate >> subject value that the authorization server is to expect when >> authenticating the respective client. >> >> Then it lists the different dn/san properties. >> >> S pozdravem, >> *Filip Skokan* >> >> >> On Thu, 4 Apr 2019 at 22:20, Justin Richer wrote: >> >>> We’ve just started implementation of SAN-based certificate >>> authentication, based on the changes in version -13 of the draft. I believe >>> this addition is a bit unclear, due to it being added so late in the >>> document process. >>> >>> My question is how does an AS determine whether to DN or SAN for >>> certificate checking? Corollary, are these mutually exclusive or can they >>> be used together? Currently, the specification text lists DN and SAN as an >>> “or” with no indication whether this is an inclusive or exclusive “or”, and >>> what to do when there’s overlap. >>> >>> This has implications both for the implementation of the server >>> processing the request as well as the client metadata model, since the >>> client fields are all in parallel to each other. I can see a few ways of >>> handling this. >>> >>> >>> 1) One of the fields takes precedence over the other. Say for example >>> you choose the DN field: if it’s set, then you do DN matching and ignore >>> the SAN fields entirely, both in the cert and in the client’s registration. >>> Inverse is true if you choose the SAN fields over the DN but the principle >>> is the same. We should be explicit if there’s an intended precedence >>> between these two, and even more explicit if the DN and SAN are at equal >>> level and the AS gets to choose. We also need to be clear if it’s an error >>> condition if both are set simultaneously, like the way that jwks and >>> jwks_uri are mutually exclusive. >>> 2) You set an explicit switch in your client model that says whether to >>> use the DN or the SAN fields in comparison, and your code branches based on >>> that to either DN or SAN processing. This could also be added as an >>> explicit client metadata field, or it could be an internal detail. If an >>> internal detail, we should be explicit about there not being a predefined >>> precedence between the fields. >>> 3) If it’s allowable to use them together, you match everything that’s >>> set in the client, and at least one field MUST be set. >>> >>> >>> What’s the intended behavior for implementers, and should we be more >>> explicit about this? We are starting our implementation with (1) pending >>> the outcome of this thread, and I’d be curious to know how others are >>> implementing this in their systems. >>> >>> Thanks, >>> — Justin >>> >>> ___ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> >> ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
+1 for the change. -- -jim Jim Willeke On Fri, Nov 30, 2018 at 5:36 PM Dick Hardt wrote: > + 1 to the change > > I'd suggest we work to define terms such as "sender constrained" in the > BCP so that it is clear what is meant by it. > > On Fri, Nov 30, 2018 at 2:24 PM Brian Campbell 40pingidentity@dmarc.ietf.org> wrote: > >> Kind of, yes. I guess so. I think. It's just semantics. But yeah. Key >> constrained might be more appropriate. But the Security Topics document >> probably should allow for both/either. >> >> I don't think that these are necessarily terms with widely agreed upon or >> understood meaning. But it was pointed out to me that the OAuth 2.0 Pop >> Architecture draft defines sender constraint and key confirmation as >> different things ( >> https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-08#section-6.2 >> and >> https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-08#section-6.3 >> <https://tools.ietf..org/html/draft-ietf-oauth-pop-architecture-08#section-6.3>). >> And the definitions their do kind of make sense when thinking about the >> words used. The line between sender and key constrained isn't exactly clear >> but it seems MTLS and token binding access tokens are more key constrained >> than sender. The -08 version of the MTLS draft dropped the use of the >> "sender constrained" terminology based on that feedback. >> >> I dunno. Maybe the Security Topics could say something in a terminology >> section that says when sender or key constrained is used within they can be >> taken to mean the same concept. Or something like that. >> >> On Fri, Nov 30, 2018 at 1:42 PM Torsten Lodderstedt < >> tors...@lodderstedt.net> wrote: >> >>> Hi Brian, >>> >>> we use „sender constrained tokens“ throughout the BCP to denote tokens >>> bound to a sender in possession of a certain key/secret and I thought that >>> was established terminology in the group. Are you suggesting „key >>> constrained” would be more appropriate? >>> >>> kind regards, >>> Torsten. >>> >>> Am 30.11.2018 um 21:02 schrieb Brian Campbell < >>> bcampb...@pingidentity.com>: >>> >>> As was pointed out to me in WGLC review of the MTLS document, >>> "sender-constrained" has or is likely to be interpreted with a pretty >>> specific meaning of the token being bound to the client and the client >>> authenticating itself to the resource and the resource checking all that >>> matches up. That makes the text more restrictive than is likely intended. >>> Perhaps the text should say something like "sender or key constrained" to >>> allow for different variants of PoP access tokens? >>> >>> >>> >>> On Thu, Nov 29, 2018 at 11:06 AM Torsten Lodderstedt < >>> tors...@lodderstedt.net> wrote: >>> >>>> Hi all, >>>> >>>> based on your feedback on the list and off list, Daniel and I polished >>>> the text. That’s our proposal: >>>> >>>> — >>>> In order to avoid these issues, clients MUST NOT use the implicit >>>> grant (response type "token") or any other response type issuing access >>>> tokens in the authorization response, such as "token id_token" and >>>> "code token id_token“, >>>> unless the issued access tokens are sender-constrained and access token >>>> injection in >>>> the authorization response is prevented. >>>> — >>>> >>>> Explantation: >>>> - we wanted to have the right balance between a generic definition of >>>> the response types we do not recommend/allow to be used and a >>>> concrete/actionable list of the affected response types. >>>> - we changed from SHOULD NOT to MUST NOT as suggested by Nat and >>>> supported by William >>>> >>>> We look forward to seeing your feedback. >>>> >>>> kind regards, >>>> Torsten. >>>> >>>> > Am 29.11.2018 um 15:15 schrieb John Bradley : >>>> > >>>> > I am ok with that. >>>> > >>>> > On Wed, Nov 28, 2018, 8:03 PM Torsten Lodderstedt < >>>> tors...@lodderstedt.net wrote: >>>> > >>>> > > Am 28.11.2018 um 23:50 schrieb n-sakimura : >>>> > > >>>> > > That works. >>>> > >>>> > Good
Re: [OAUTH-WG] Questions on urn:ietf:wg:oauth:2.0:oob
Thanks for all the feedback. -- -jim Jim Willeke On Tue, Oct 10, 2017 at 11:02 AM, John Bradley <ve7...@ve7jtb.com> wrote: > urn:ietf:wg:oauth:2.0:oob is a google thing that is not part of the OAuth > 2 specification. > > I think it was mostly a windows thing. > > It is not a real redirect URI it is used as a flag to the authorization > server to have the result returned “Out Of Band” and the user cut and paste > the token. > > On windows applications could snoop the title bars of other apps so > programatically retrieve the token value from the title bar. > > I don’t really want to put effort into expanding all the reasons this is > not secure. > > I don’t honestly know what would happen if you sent that redirect URI to a > non Google AS probably nothing good. > It is not part of the OAuth specification and not something people should > use without having a good reason and understanding the security > implications. > > William and I documented several ways to impliment native applications on > OSX and Windows in RFC8252. > > On windows you are really best off using a UWP app and the native token > broker with the code flow. > > Documentation > https://developers.google.com/api-client-library/python/auth/installed-app > > This value signals to the Google Authorization Server that the > authorization code should be returned in the title bar of the browser, with > the page text prompting the user to copy the code and paste it in the > application. This is useful when the client (such as a Windows application) > cannot listen on an HTTP port without significant client configuration. > > When you use this value, your application can then detect that the page > has loaded, and can read the title of the HTML page to obtain the > authorization code. It is then up to your application to close the browser > window if you want to ensure that the user never sees the page that > contains the authorization code. The mechanism for doing this varies from > platform to platform. > > If your platform doesn't allow you to detect that the page has loaded or > read the title of the page, you can have the user paste the code back to > your application, as prompted by the text in the confirmation page that the > OAuth 2.0 server generates. > > John B. > > On Oct 10, 2017, at 8:22 AM, Jim Willeke <j...@willeke.com> wrote: > > Wondering if you could help with Questions on urn:ietf:wg:oauth:2.0:oob as > it appears to be an almost common usage, but no IETF documentation or > registration that we can find on the defined usage. > > This has come up on several occasions. > >- https://stackoverflow.com/q/46643795/88122 >- http://lists.jboss.org/pipermail/keycloak-dev/2014-May/001814.html >- https://github.com/doorkeeper-gem/doorkeeper/issues/514 >- https://www.ietf.org/mail-archive/web/oauth/current/msg09974.html > > > Should it be registered or defined? > (or am I missing something?) > > With best regards, > > -- > -jim > Jim Willeke > ___ > 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-WG] Questions on urn:ietf:wg:oauth:2.0:oob
Wondering if you could help with Questions on urn:ietf:wg:oauth:2.0:oob as it appears to be an almost common usage, but no IETF documentation or registration that we can find on the defined usage. This has come up on several occasions. - https://stackoverflow.com/q/46643795/88122 - http://lists.jboss.org/pipermail/keycloak-dev/2014-May/001814.html - https://github.com/doorkeeper-gem/doorkeeper/issues/514 - https://www.ietf.org/mail-archive/web/oauth/current/msg09974.html Should it be registered or defined? (or am I missing something?) With best regards, -- -jim Jim Willeke ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Call for Adoption: JSON Web Token Best Current Practices
+1 for adoption -- -jim Jim Willeke On Thu, Jul 20, 2017 at 8:37 AM, Rifaat Shekh-Yusef <rifaat.i...@gmail.com> wrote: > All, > > We would like to get a confirmation on the mailing list for the adoption > of the *JSON Web Token Best Current Practices* as a WG document > https://datatracker.ietf.org/doc/draft-sheffer-oauth-jwt-bcp/ > > Please, let us know if you support or object to the adoption of this > document. > > Regards, > Rifaat > > > ___ > 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] New OAuth I-D: Incremental Auth
I know we add scopes based on the Authorization Server determining that the Resource Owner is also a "Paying Customer". (Well using OIDC so we KNOW they are a paying customer.) -- -jim Jim Willeke On Fri, Jul 7, 2017 at 9:03 PM, William Denniss <wdenn...@google.com> wrote: > > On Fri, Jul 7, 2017 at 1:50 PM, Sergey Beryozkin <sberyoz...@gmail.com> > wrote: > >> Hi >> On 07/07/17 18:56, William Denniss wrote: >> >>> What you describe is incremental auth. >>> >>> Thanks... FYI, I thought of doing some work around it after browsing >> through the Google docs; the line about the "asking to approve the purchase >> of the kitchen sink at the authentication time is a death of the modern >> web" (or something similar that I read on this list) was even more >> convincing :-) >> > > I hear ya :-) > > We ended up requiring that apps *don't* ask for the kitchen sink upfront > in our API policies https://developers.google.com/ > terms/api-services-user-data-policy#request-relevant-permissions . > Definitely makes for a bad user experience if users don't know why they are > being asked to approve the request's scope. > > > >> >> Aside: Do you return the "scope" in the token response as required when >>> the scope in the response is not identical to the request (§ 5.1 < >>> https://tools.ietf.org/html/rfc6749#section-5.1>, parameter: scope)? >>> >>> Yes, the token service is doing it by default for all the returned >> access tokens >> >> My only question is: does the client expect this? The spec talks about >>> the authorization server *reducing* scope in a few places (in § 3.3 < >>> https://tools.ietf.org/html/rfc6749#section-3.3>, "The authorization >>> server MAY fully or partially ignore the scope requested by the client" and >>> § 10.3 <https://tools.ietf.org/html/rfc6749#section-10.3> "The >>> authorization server SHOULD take the client identity into account when >>> choosing how to honor the requested scope and MAY issue an access token >>> with less rights than requested."). It never talks about *increasing* >>> scope (other than it can't be done during refresh). >>> >>> So I think some normative language around the potential to increase the >>> scope of the request for confidential clients (in either the way you >>> describe, or the way I described in the draft) is warranted. >>> >>> Open question: should we require an indication from the client if they >>> *want* the scope increase? That's what include_granted_scopes was designed >>> to do. To allow clients to specify if this is behavior they desire. >>> >> Right, I see how a proposed "include_granted_scopes" can make it non >> ambiguous >> >>> >>> >>> The more innovative part of the spec I think is the public (native app) >>> client incremental auth – as native apps cannot use the methods you >>> discuss, or the ones Google has supported for a while for confidential >>> clients. That said, if we write this – I think we may as well formally >>> document approaches for confidential clients too. >>> >>> >> thanks, Sergey >> >>> >>> On Fri, Jul 7, 2017 at 9:24 AM, Sergey Beryozkin <sberyoz...@gmail.com >>> <mailto:sberyoz...@gmail.com>> wrote: >>> >>> Hi >>> >>> Re the confidential client: let me explain please how we >>> experimented with this feature when the code flow is used. >>> >>> 1. Client requests a scope 'a' for a given User, it gets approved by >>> the user, the clients gets a code and exchanges it for a token. >>> >>> 2. At some later stage Client requests a scope 'b' for the same user >>> and if an access token for a given Client + User combination exists >>> and the incremental authorization is supported (we use a different >>> term for now) than the service finds out from this token that 'a' >>> has already been approved and offers a consent screen where a user >>> sees 'a' being selected and needs to approve 'b'. >>> >>> 3. User approves 'b'. The client gets a new code back and exchanges >>> it for a new token which now has "a" and "b". >>> >>> At this point a client has 2 tokens, one with the "a" scope and >>> another with the "a" and "b" scopes and
Re: [OAUTH-WG] Call for adoption: OAuth Security Topics
+! I agree this is needed. -- -jim Jim Willeke On Thu, Feb 2, 2017 at 4:33 PM, John Bradley <ve7...@ve7jtb.com> wrote: > I am in favour of adoption. > > On Feb 2, 2017, at 4:09 AM, Hannes Tschofenig <hannes.tschofe...@gmx.net> > wrote: > > > > Hi all, > > > > this is the call for adoption of the 'OAuth Security Topics' document > > following the positive call for adoption at the last IETF > > meeting in Seoul. > > > > Here is the document: > > https://tools.ietf.org/html/draft-lodderstedt-oauth-security-topics-00 > > > > The intention with this document is to have a place to collect > > discussions and conclusions around OAuth 2.0 security and to reference > > the actual solution specifications. > > > > Please let us know by Feb 16th whether you accept / object to the > > adoption of this document as a starting point for work in the OAuth > > working group. > > > > Ciao > > Hannes & Derek > > > > ___ > > 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] About Big Brother and draft-campbell-oauth-resource-indicators-00
I liked the usage in https://tools.ietf.org/html/rfc7515 Collision-Resistant Name A name in a namespace that enables names to be allocated in a manner such that they are highly unlikely to collide with other names. Examples of collision-resistant namespaces include: Domain Names, Object Identifiers (OIDs) as defined in the ITU-T X.660 and X.670 Recommendation series, and Universally Unique IDentifiers (UUIDs) [RFC4122 <https://tools.ietf.org/html/rfc4122>]. When using an administratively delegated namespace, the definer of a name needs to take reasonable precautions to ensure they are in control of the portion of the namespace they use to define the name. -- -jim Jim Willeke On Thu, Nov 17, 2016 at 10:23 AM, Vivek Biswas <vivek.bis...@oracle.com> wrote: > +1 to *It MAY be an absolute URI*, as specified by Section 4.3 of > [RFC3986]". > > Since the Audience Restriction can be a logical name to be interpreted by > the Resource Server, if it really wants to enforce the audience check for a > set of Resources it wants to protect. > Hence, a logical name can be an absolute URI or a String as well. > > Regards > Vivek Biswas, CISSP > Consulting Member, Security > Oracle Corporation. > > > > *From:* Denis [mailto:denis.i...@free.fr] > *Sent:* Tuesday, November 15, 2016 3:50 AM > *To:* oauth@ietf.org > *Subject:* [OAUTH-WG] About Big Brother and draft-campbell-oauth-resource- > indicators-00 > > > > Hello everybody, > > Since I am not present at the meeting, I read the minutes from the first > session, in particular: > > Brian Campbell and John did a draft allowing the client to tell the AS > where it plans to use the token > draft-campbell-oauth-resource-indicators > > This enables the AS to audience restrict the access token to > the resource > Phil Hunt: We should keep the audience restriction idea on > the table > > The introduction contains the following sentences: > > Several years of deployment and implementation experience with OAuth 2.0 > [RFC6749] has uncovered a need, in some circumstances, > for the client to explicitly signal to the authorization sever where it > intends to use the access token it is requesting. > > A means for the client to signal to the authorization sever where it > intends to use the access token it's requesting is important and useful. > > The document contains a "security considerations" section but > unfortunately no "privacy considerations" section. > > Clause 2 states: > > The client may indicate the resource server(s) for which it is requesting > an access token by including the > following parameter in the request. > > resource > > OPTIONAL. The value of the resource parameter indicates a resource server > where the requested > access token will be used.* It MUST be an absolute URI*, as specified by > Section 4.3 of[RFC3986], > > With such an approach, the authorization server would have the ability to *act > as a Big Brother *and hence to know exactly > where the user will be performing activities. > > However, some users might be concerned with their privacy, and would like > to restrict the use of the access token > to some resource servers without the authorization server knowing which > are these resource servers. > > The key point is whether the information is primarily intended to the > authorization server or to the resource server(s). > > I believe that it is primarily intended to the resource server(s) rather > than to the authorization server in order to be included > in an access token. Obviously, the information needs to transit through > the authorization sever, that should simply be copied > and pasted into the access token. Its semantics, if any, does not > necessarily needs to be interpreted by the authorization sever. > > I believe that a "privacy considerations" section should be added. > > The sentence "*It MUST be an absolute URI*, as specified by Section 4.3 > of [RFC3986]" should be removed or > replaced by : "*It MAY be an absolute URI*, as specified by Section 4.3 > of [RFC3986]". > > Obviously, other changes would be necessary too. > > Denis > > ___ > 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] Multiple authorization servers for one resource server
Would a header be a concern if TLS was used for transportation? -- -jim Jim Willeke On Sat, Mar 12, 2016 at 10:03 AM, Phil Hunt (IDM) <phil.h...@oracle.com> wrote: > A header might open another attack vector. Better to parse the jwt and > look for the issuer assuming the jwt validates. > > Phil > > On Mar 12, 2016, at 09:02, Jim Willeke <j...@willeke.com> wrote: > > Why not register JWT as an access token type > <https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#token-types> > and then the the Issuer is implied? > > -- > -jim > Jim Willeke > > On Sat, Mar 12, 2016 at 8:32 AM, Mike Schwartz <m...@gluu.org> wrote: > >> Kawasaki-san, >> >> This is a really good question: how to know the issuer of a bearer token. >> Is there a header that could be added to specify the issuer, or other >> important metadata? >> >> - Mike >> >> >> - >> Michael Schwartz >> Gluu >> Founder / CEO >> m...@gluu.org >> >> ___ >> 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] Multiple authorization servers for one resource server
Why not register JWT as an access token type <https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#token-types> and then the the Issuer is implied? -- -jim Jim Willeke On Sat, Mar 12, 2016 at 8:32 AM, Mike Schwartz <m...@gluu.org> wrote: > Kawasaki-san, > > This is a really good question: how to know the issuer of a bearer token. > Is there a header that could be added to specify the issuer, or other > important metadata? > > - Mike > > > - > Michael Schwartz > Gluu > Founder / CEO > m...@gluu.org > > ___ > 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
