Re: [OAUTH-WG] Call for adoption - Identity Chaining

I support adoption > On Nov 14, 2023, at 9:58 AM, Rifaat Shekh-Yusef > wrote: > > All, > > This is an official call for adoption for the Identity Chaining draft: > https://datatracker.ietf.org/doc/draft-schwenkschuster-oauth-identity-chaining/ > > Please, reply on the mailing list and let

Re: [OAUTH-WG] Call for adoption - Transaction Tokens

I support adoption > On Nov 14, 2023, at 9:57 AM, Rifaat Shekh-Yusef > wrote: > > All, > > This is an official call for adoption for the Transaction Tokens draft: > https://datatracker.ietf.org/doc/draft-tulshibagwale-oauth-transaction-tokens/ > > Please, reply on the mailing list and let

Re: [OAUTH-WG] IPR Disclosure - OAuth 2.0 Security Best Current Practice

I am not aware of any IPR related to this document.  John B. Sent from my iPhoneOn Oct 4, 2023, at 12:10 PM, Tschofenig, Hannes wrote: In my earlier email I forgot to include John.   John, I also need your confirmation!   Von: OAuth Im Auftrag von Tschofenig, Hannes Gesendet: Mittwoch,

Re: [OAUTH-WG] Call for adoption - JWT and CWT Status List

+1 for adoption On Sat, Sep 30, 2023, 9:53 AM Rifaat Shekh-Yusef wrote: > All, > > This is an official call for adoption for the *JWT and CWT Status List* > draft: > https://datatracker.ietf.org/doc/draft-looker-oauth-jwt-cwt-status-list/ > > Please, reply *on the mailing list *and let us know

Re: [OAUTH-WG] Call for adoption - Protected Resource Metadata

I support addoption > On Aug 23, 2023, at 3:01 PM, Rifaat Shekh-Yusef > 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/ > > Please, reply on the mailing list and

Re: [OAUTH-WG] [External Sender] Re: Call for adoption - SD-JWT-based Verifiable Credentials

I support adoption. Sent from my iPhoneOn Jul 30, 2023, at 8:22 AM, George Fletcher wrote:+1 for meOn Sat, Jul 29, 2023 at 3:36 PM Michael Prorock wrote:I support adoption - but would request that if a group dedicated to verifiable credentials is created prior to this draft

Re: [OAUTH-WG] [IANA #1270370] Request to register OAuth Authorization Server Metadata: dpop_signing_alg_values_supported

I approve the request. Sent from my iPhoneOn Apr 5, 2023, at 1:59 PM, Dick Hardt wrote:I approve this request. On Wed, Apr 5, 2023 at 8:47 AM David Dong via RT wrote:Dear Michael, Nat, John and Dick (cc: oauth WG / review mailing list), As the designated

Re: [OAUTH-WG] AD review of draft-ietf-oauth-step-up-authn-challenge-08

Looking at Roman’s question on LoA definitions. RFC6711 defined an IANA registry for ACR short names. It might be worth referencing that. The registration is a bit SAML oriented but can be used for any protocol, including OIDC. John B. > On Feb 17, 2023, at 4:57 PM, Vittorio Bertocci >

Re: [OAUTH-WG] DPoP - IPR Disclosure

I am not aware of any IPR relating to this document. John B. Sent from my iPhone > On Aug 10, 2022, at 5:42 PM, Brian Campbell > wrote: > >  > I am not aware of any IPRs associated with this document. > >> On Wed, Aug 10, 2022 at 3:38 PM Rifaat Shekh-Yusef >> wrote: >> Daniel, Brian,

Re: [OAUTH-WG] Call for adoption - Step-up Authentication

I support this work. On Tue, Apr 26, 2022, 12:35 PM David Waite wrote: > I support the working group adopting this work. > > On Apr 26, 2022, at 3:46 AM, Rifaat Shekh-Yusef > wrote: > > This is a call for adoption for the *Step-up Authentication* document > >

Re: [OAUTH-WG] WGLC for DPoP Document

I support publication. John Bradley -- Original Message -- From: "Nat Sakimura" To: "Rifaat Shekh-Yusef" ; "oauth" Sent: 4/7/2022 10:37:21 PM Subject: Re: [OAUTH-WG] WGLC for DPoP Document Thanks for an excellent work. I am happy that the public key

Re: [OAUTH-WG] Second WGLC for JWK Thumbprint URI document

I support publication. -- Original Message -- From: "Rifaat Shekh-Yusef" To: "oauth" Sent: 2/21/2022 10:12:00 AM Subject: [OAUTH-WG] Second WGLC for JWK Thumbprint URI document All, Mike and Kristina made the necessary changes to address all the great comments received during the

Re: [OAUTH-WG] DPoP and implicit/hybrid flows

key. This has nothing to do with access tokens, or even calling an > identity API like a UserInfo Endpoint. DPoP doesn’t help with any of that > since DPoP is about access tokens. > > — Justin > > On Jul 16, 2021, at 1:18 PM, John Bradley wrote: > > Binding the token would be requir

Re: [OAUTH-WG] DPoP and implicit/hybrid flows

Binding the token would be required for OAuth or Connect to meet the SP800-63 FAL3 requirements. Something like DPoP might work. I don't think DPoP itself should directly add support. I don't know if people really care about FAL3, unfourtunatly the simple solution of using token-binding seems

Re: [OAUTH-WG] New Version Notification for draft-ietf-oauth-dpop-03.txt

” is based on. I’ve implemented both approaches on several > platforms now, and I greatly prefer the fixed hash.  > > It’s a new name because it is a new claim with new contents and new > semantics. > >  — Justin > >> On Apr 9, 2021, at 11:20 AM, John Bradley > <mailto

Re: [OAUTH-WG] Fwd: New Version Notification for draft-ietf-oauth-dpop-03.txt

I think that using "auth" with the fixed full sha256 hash is fine. The original response size reasons for truncating the hash in the definition of at_hash are no longer really neccicary in current browsers and networks. A new claim is fine. On 4/9/2021 11:03 AM, Brian Campbell wrote: > For a

Re: [OAUTH-WG] JWT Secured Authorization Request (JAR): IPR Confirmation

I know of no IPR, and make the required contributions again. On Mon, Sep 21, 2020, 4:22 PM Hannes Tschofenig wrote: > Hi Mike, Nat, John, > > I am updating the shepherd writeup for the "The OAuth 2.0 Authorization > Framework: JWT Secured Authorization Request (JAR)" specification, see >

Re: [OAUTH-WG] Omit "jwk" (or use "kid" instead) in DPoP Proof?

+1 On 9/8/2020 7:45 PM, Brian Campbell wrote: > Indeed there are cases, as you point out, where the key might be > knowable to the server via some other means, which makes the "jwk" > header in the DPoP proof not strictly necessary. And while omitting > the key in such cases would reduce the size

Re: [OAUTH-WG] Call for adoption - OAuth 2.1 document

I support addoption On 7/15/2020 3:32 PM, Neil Madden wrote: > I support adoption.  > >> On 15 Jul 2020, at 18:42, Rifaat Shekh-Yusef >> wrote: >> >>  >> All, >> >> This is a *call for adoption* for the following *OAuth 2.1* document >> as a WG document: >>

Re: [OAUTH-WG] Downgrade attacks on PKCE

Definatly 2. To my mind if you get a challange and dont get a verifyer that must fail.  I guess the querstion is if there is a veriyer with no challange what to do.  We diden't specify that.   I would reject that as a config error or indication of a MIM in the front channel. I think that is

Re: [OAUTH-WG] DPoP - new authorization scheme / immediate usability concerns

I agree that without a tight binding between the RS and AS we need to revisit RS meta-data. It is a can of worms however. On 4/17/2020 2:39 PM, Torsten Lodderstedt wrote: > I think the same is already true for mTLS. Solving it in an > interoperable way would require some metadata about RS and

Re: [OAUTH-WG] Call for Adoption: DPoP

+1 On 3/17/2020 12:37 PM, Anthony Nadalin wrote: > > +1 > >   > > *From:* OAuth *On Behalf Of * Mike Jones > *Sent:* Tuesday, March 17, 2020 8:14 AM > *To:* Rifaat Shekh-Yusef ; oauth > *Subject:* [EXTERNAL] Re: [OAUTH-WG] Call for Adoption: DPoP > >   > > I am for adoption of DPoP. > >   > >   

Re: [OAUTH-WG] [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits of jwks_uri

I remember the fight to have diffrent keys defined for signing and encryption. I am glad times have changed.   You can use difffent keys now with a JWKS URI that allows you to separate the private keys. The question is if you want the verifier to be able to differentiate the purpose. One way

Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwsreq-19: (with DISCUSS and COMMENT)

>From the discussions I have had, I agree with Nat's assment. John B. On 1/31/2020 12:06 AM, Nat Sakimura wrote: > Hi > > Re: JWT > I understand your concern and we can put some explanatory notes. Having > said that, JAR is still a valid JWT, I think :-) > > Re: client_id > We actually discussed

[OAUTH-WG] Fwd: [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC request object

-- Forwarded message - From: John Bradley Date: Sat, Jan 18, 2020, 9:31 PM Subject: Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC request object To: Benjamin Kaduk If you put the iss in the JWE header it is integrity protected, as JWE only

Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC request object

I agree with the IESG reasoning that merging is problimatic.  Once we allow that given a unknown list of possible paramaters with diffrent security properties it would be quite difficult to specify safely. Query paramaters can still be sent outside the JAR, but if they are in the OAuth registry

Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC request object

5.3> pointer. Can this > parameter replication be used for client_id or the client_id ass "iss" > even though it isn't explicitly mentioned in the JAR spec? > > On 11/01/2020 02:58, John Bradley wrote: >> Right we just don't say to put the iss there in OIDC if it's >

Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC request object

l/rfc7519#section-5.3. (Thanks to Dick Hardt > for bringing this need to my attention as we were finishing the JWT spec.) > > > >-- Mike > > > > *From:* OAuth *On Behalf Of * John Bradley > *Sent:* Friday, Ja

Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object

t;> OP servers which require request_uri registration > >> (require_request_uri_registration=true) and don't want to index all > >> registered request_uri's, also have no good way to process a request_uri > >> if the client_id isn't present as top-level parameter. >

Re: [OAUTH-WG] PAR: pushed requests must become JWTs

ike it) qualifies it such that > there aren't interoperability questions because it's only an implementation > detail to the AS who both produces the URI and consumes its content. > > On Fri, Jan 10, 2020 at 12:48 PM John Bradley wrote: > >> It may be a challenge to change text

Re: [OAUTH-WG] PAR: pushed requests must become JWTs

It may be a challenge to change text saying that the contents of the resource could be something other than a request object. If not a request object then what and how is that interoperable are likely AD questions. I could perhaps see changing it to must be a request object, or other format

Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object

ted here before, to have > a fixed core set of parameters inside the JAR and a mixed set of variable > parameters outside the JAR. > > What if by “merge” we really mean “you can’t repeat things in both places > but you can have fields in either”. > > — Justin > > On Jan 10,

Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object

0 schrieb John Bradley : > > A client could duplicate those outside the request object for some sort of > backwards compatability but they will be ignored. > > Is this used for backward compatibility with the OIDC servers? > > What we have lost is the merge capability. There a

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

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Pushed Authorization Requests

I support addoption On 12/17/2019 11:01 AM, Aaron Parecki wrote: > I support the adoption of PAR. > > Aaron Parecki > > > On Tue, Dec 17, 2019 at 4:59 AM Rifaat Shekh-Yusef > mailto:rifaat.i...@gmail.com>> wrote: > > All, > > This is a call for adoption of for the OAuth 2.0 Pushed >

Re: [OAUTH-WG] JWT Secured Authorization Request (JAR) vs OIDC request object

I also slightly prefer the merge approach. There are plusses and minuses to both. Changing again now that it is past ISEG review and backing out a Discuss will add another three to six months at this point, if we can get them to agree to the change. John B. On Tue, Dec 10, 2019, 11:29 PM Nat

Re: [OAUTH-WG] [Technical Errata Reported] RFC8252 (5848)

This is not really an eratta. Asome point we need to update the BCP with a updated RFC. Perhaps the time is now to start a new draft that can capture the changes in iOS, OSX and others. John B. On Mon, Aug 26, 2019, 10:46 PM William Denniss wrote: > Process-wise I'm not sure if errata

Re: [OAUTH-WG] Info on how to implement a server

The openID Connect kind of OAuth server. OAuth on its own is not designed to be secure for identity federation. John B. On 8/17/2019 1:23 PM, Salz, Rich wrote: > > What’s the WG consensus (heh) on the best guide to adding OAUTH > support to an existing server so that it can act as an identity >

Re: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-token-exchange-18: (with COMMENT)

Thanks On Sun, Jul 21, 2019, 12:31 PM Barry Leiba wrote: > Thanks, Brian! > > Barry > > On Sun, Jul 21, 2019 at 11:43 AM Brian Campbell > wrote: > > > > https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-19 has been > published with the updates discussed in this thread. > > > > On

Re: [OAUTH-WG] MTLS and Native apps Best practices

The mtls spec doesn't cover the authorization endpoint. Mtls via the browser is a whole world of pain. I believe that for a native app to use mtls via a chrome custom tab or Safari view controller you need to provision a certificate and private key to the system keystore. It is not something

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

I agree this should be adopted as a working group document. On 4/8/2019 7:07 PM, Hannes Tschofenig wrote: 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:

Re: [OAUTH-WG] Resource Indicators - IPR Disclosure

I am not aware of any IPR related to this document On Tue, Feb 26, 2019, 4:41 AM Hannes Tschofenig wrote: > I am not aware of any IPR related to this document. > > > > *From:* Rifaat Shekh-Yusef > *Sent:* Montag, 25. Februar 2019 22:15 > *To:* Brian Campbell > *Cc:*

Re: [OAUTH-WG] popular apps that use appauth?

those issues should be explicitly acknowledged in the best > practices document, so that developers running into them realize they are > now issues and not something they are doing wrong. > > On Mon, Feb 25, 2019 at 3:21 AM John Bradley wrote: > >> On Windows Web Authentication b

Re: [OAUTH-WG] popular apps that use appauth?

On Windows Web Authentication broker is a option. https://docs.microsoft.com/en-us/uwp/api/Windows.Security.Authentication.Web I have encouraged Apple to provide a SSO service on OSX. The availability of WebAuthn in browsers may make the platforms rethink some things. John B. On Mon, Feb 25,

Re: [OAUTH-WG] popular apps that use appauth?

I have been told that YouTube and other Google apps on iOS use the AppAuth flow.  I don't know if they use the AppAuth SDK or just follow the pattern. Interestingly I was told that switching to AppAuth increased login conversions for them with YouTube.   That was a while ago. John B. On

Re: [OAUTH-WG] MTLS endpoints & discovery (was something else)

I agree. If someone really wants separate meta-data nothing stops them from having a separate AS with its own meta-data. John B. On 2/20/2019 7:04 PM, Torsten Lodderstedt wrote: +1 for defining an optional mtls endpoints section I first leaned towards a second metadata file, mainly due to

Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

ill exist in practice tho > as it still end up in the resulting aud of the issued token. > This is 9 months old info hence > > On Sun, Jan 20, 2019 at 17:58 John Bradley wrote: > >> What is the parameter that Microsoft is using? >> On 1/20/2019 3:59 PM, Vittorio Bertocci wrote

Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

*From:* OAuth mailto:oauth-boun...@ietf.org>> *On Behalf Of * John Bradley *Sent:* Saturday, January 19, 2019 9:01 AM *To:* Brian Campbell mailto:bcampb...@pingidentity.com>> *Cc:* Vittorio Bertocci mailto:Vittorio=40auth0@dmarc.ietf.org>>; IETF oauth WG mailto:o

Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

s that's too much to be left as an exerciser to the reader? >>> And some text should be added and/or adjusted so the resource-indicators >>> draft would be a little more open/clear about the parameter value >>> potentially being more of a logical or abstract identifier and not

Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

n, Annabelle < richa...@amazon.com> wrote: > Doesn’t the “scope” parameter already provide a means of specifying a > logical identifier? > > > > -- > > Annabelle Richard Backman > > AWS Identity > > > > > > *From: *OAuth on behalf of Vittorio Bert

Re: [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

We have discussed this. Audiences can certainly be logical identifiers. This however is a more specific location.  The AS is free to map the location into some abstract audience in the AT. From a security point of view once the client starts asking for logical resources it can be tricked

Re: [OAUTH-WG] Resource Indicators - IPR Disclosure

I am not aware of any IPR related to this specification On 1/4/2019 12:42 PM, Rifaat Shekh-Yusef wrote: Authors, As part of the write-up for the Resource Indicators document, we need an IPR disclosure from all of you. Are you aware of any IPR related to the following Resource Indicators

Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

I think that works for those browsers if no certificates are installed for the browser.   We should test, but I think if any certificates are available to the browser then it will prompt. John B. On 12/17/2018 1:52 PM, Neil Madden wrote: I am currently running a Tomcat instance that I have

Re: [OAUTH-WG] MTLS and in-browser clients using the token endpoint

Yes that is a general problem with browsers and MTLS. A separate token endpoint is probably useful. I don't really see SPA doing mutual TLS as likely, however once MTLS is turned on on the token endpoint for some clients it can mess up other browser and non browser clients. A separate

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

; > Am 03.12.2018 um 12:59 schrieb John Bradley : > > > > I agree that the hair on fire messaging is over stated. > > > > This is still a document in development and not yet a BCP. No new > vunerable have been found, but attackers are evolving. > > You are right. Ba

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

>> > 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

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

pp’s layering >> >> All Angular apps I have seen so far work that way. And it makes a lot of >> sense to me. The backend can aggregate and optimize access to the >> underlying services without the need to fully expose them. >> >> Am 02.12.2018 um 00:44 schrieb John Bradley

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

How is that different from a regular server client with a web interface if the backed is doing the API calls to the RS? On 12/1/2018 12:25 PM, Torsten Lodderstedt wrote: I forgot to mention another (architectural) option: split an application into frontend provided by JS in the browser and a

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

I am ok with that. On Wed, Nov 28, 2018, 8:03 PM Torsten Lodderstedt > > Am 28.11.2018 um 23:50 schrieb n-sakimura : > > > > That works. > > Good! > > I just realized this text has an issue with „token“ (only). It would allow > „token“ to be used if the token would sender constrained. This

Re: [OAUTH-WG] [Openid-specs-ab] OAuth Security Topics -- Recommend authorization code instead of implicit

regards, Torsten. Am 27.11.2018 um 20:54 schrieb John Bradley : I talked to Nat about this a bit today. The thing he is concerned about is mostly around the self issued IDP that doesn't have a token endpoint(atleast not easaly). The main use case for that is the id_token response type where claims

Re: [OAUTH-WG] [Openid-specs-ab] OAuth Security Topics -- Recommend authorization code instead of implicit

I talked to Nat about this a bit today. The thing he is concerned about is mostly around the self issued IDP that doesn't have a token endpoint(atleast not easaly). The main use case for that is the id_token response type where claims are retuned in the id_token. Because it is fragment encoded

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

t; >>>> Post response works OK for server based clients. I don't think >> POST works for single page applications. >> > >>>> >> > >>>> Basically that would be something more like postmessage between >> two JS apps. >> > >>>

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

ing ID Tokens and the Form Post > Response Mode are in scope. > > > > -- Mike > > > > *From:* OAuth *On > Behalf Of * John Bradley > *Sent:* Tuesday, November 20, 2018 7:47 AM > *To:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] OAuth Security Topics -- Recommend

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

Yes the at_hash protects the client from accepting an injected AT. Unfortunately it doesn't do anything to protect against leakage in logs or redirects. So without the AT using some sort of POP mechanism it is hard to say sending it in a redirect is a good security practice. John B. On

Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-jwsreq

The JWT was done by the OAuth WG. Some wanted it to be core to OAuth and others wanted it to be entirely optional so that people would not feel obligated to use it for access tokens. JWT is used in a number of OAuth specs now and provides consistency for some common elements like issuer ,

Re: [OAUTH-WG] MTLS - IPR Disclosure

I am not aware of any IPR. Sent from Mail for Windows 10 From: Rifaat Shekh-Yusef Sent: Tuesday, July 17, 2018 10:06 AM To: oauth Subject: [OAUTH-WG] MTLS - IPR Disclosure Authors, As part of the write-up for the OAuth MTLS document, we need an IPR disclosure from all of you.. Are you aware

Re: [OAUTH-WG] Call for adoption of "JWT Response for OAuth TokenIntrospection"

I am in favor of adoption. Sent from Mail for Windows 10 From: Rifaat Shekh-Yusef Sent: Thursday, July 19, 2018 1:44 PM To: oauth Subject: [OAUTH-WG] Call for adoption of "JWT Response for OAuth TokenIntrospection" Hi all, This is the call for adoption of the 'JWT Response for OAuth Token

Re: [OAUTH-WG] Call for adoption for "Resource Indicators for OAuth 2.0"

I accept the adoption of this document. Sent from Mail for Windows 10 From: Rifaat Shekh-Yusef Sent: Thursday, July 19, 2018 4:02 PM To: oauth Subject: [OAUTH-WG] Call for adoption for "Resource Indicators for OAuth 2.0" Hi all, This is the call for adoption of the 'Resource Indicators for

Re: [OAUTH-WG] Reuse of "state" across different AS in draft-bradley-oauth-jwt-encoded-state-08

Thanks On Sat, May 19, 2018, 3:09 PM Daniel Fett <daniel.f...@sec.uni-stuttgart.de> wrote: > Am 18.05.2018 um 18:20 schrieb John Bradley: > > I am not against having "as" as REQUIRED. > > While we are at it should we recommend that rfp be single use? >

Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps?

one SPA may turn out to be impossible to completely secure. However that wont stop people from creating them. We can try to put together the best advice, and limit the damage. John B. Sent from Mail for Windows 10 From: Neil Madden Sent: Friday, May 18, 2018 7:38 PM To: John Bradley; Jim

Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps?

. Mozilla could use more resources so they can prioritize it. Safari is of course anyone’s guess. I don’t expect it to be years before it deployed widely enough to support. John B. Sent from Mail for Windows 10 From: Jim Manico Sent: Friday, May 18, 2018 6:43 PM To: John Bradley Cc: David

Re: [OAUTH-WG] is updated guidance needed for JS/SPA apps?

Yes that was the original intent to have the AT be short lived and refresh the AT via the authorization endpoint based on the session cookie. The session cookie should also be flagged as http only to protect it. Having a refresh token in local storrage may introduce new security issues unless

Re: [OAUTH-WG] Reuse of "state" across different AS in draft-bradley-oauth-jwt-encoded-state-08

I am not against having "as" as REQUIRED. While we are at it should we recommend that rfp be single use? This draft hangs around as a ID and probably is not read by most people. We may also want to mention it in security topics if we haven't. I need to update this in the next couple of weeks

Re: [OAUTH-WG] OAuth Webex Info

Sorry, you must have ended the call before I saw this. John B. > On May 7, 2018, at 12:38 PM, Hannes Tschofenig > wrote: > > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the

Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07

eil Madden <neil.mad...@forgerock.com> wrote: > > Responses inline again. > > On Mon, 30 Apr 2018 at 19:44, John Bradley <ve7...@ve7jtb.com > <mailto:ve7...@ve7jtb.com>> wrote: > Inline. > > >> On Apr 30, 2018, at 12:57 PM, Neil Madden <neil.mad.

Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07

0, 2018 at 9:57 AM, Neil Madden <neil.mad...@forgerock.com > <mailto:neil.mad...@forgerock.com>> wrote: > > > On 30 Apr 2018, at 15:07, John Bradley <ve7...@ve7jtb.com > > <mailto:ve7...@ve7jtb.com>> wrote: > > > My concern is that people will s

Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07

Inline. > On Apr 30, 2018, at 12:57 PM, Neil Madden <neil.mad...@forgerock.com > <mailto:neil.mad...@forgerock.com>> wrote: > > Hi John, > >> On 30 Apr 2018, at 15:07, John Bradley <ve7...@ve7jtb.com >> <mailto:ve7...@ve7jtb.com>> w

Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07

re probably not too far off for SHA-1 >> now. As far as I am aware, we’re nowhere near those kinds of attacks on >> SHA-256, but I’d prefer that there was a backup plan in place already >> rather than waiting to see (and waiting for everyone to have hard-coded >> SHA-256 eve

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Incremental Authorization

+1 for adoption. On Mon, Apr 16, 2018, 7:47 AM Rifaat Shekh-Yusef wrote: > All, > > We would like to get a confirmation on the mailing list for the adoption of > the *OAuth 2.0 Incremental Authorization* as a WG document >

Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07

Inline Snip > > > 12. The use of only SHA-256 fingerprints means that the security strength of > the sender-constrained access tokens is limited by the collision resistance > of SHA-256 - roughly “128-bit security" - without a new specification for a > new thumbprint algorithm. An

Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07

it’s a MUST requirement to have one-way SSL from LBR to >> AuthzServer/Backend Server, so that the headers passed are not compromised. >> >> This is a MOST common scenario in a real world. And we don’t want >> everyone come up with their own names for the header. There should

Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07

t or not.” > > Kind regards, > Neil > -- > > On Thursday, Mar 29, 2018 at 4:47 pm, John Bradley <ve7...@ve7jtb.com > <mailto:ve7...@ve7jtb.com>> wrote: > Thanks for the feedback. We will review your comments and reply. > > One data point is that

Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07

Thanks for the feedback. We will review your comments and reply. One data point is that this will not be the only POP spec. The spec using token binding vs mtls has better privacy properties. It is UK Open banking that has pressed us to come up with a standard to help with

Re: [OAUTH-WG] Adam Roach's Discuss on draft-ietf-oauth-discovery-08: (with DISCUSS and COMMENT)

etaphor) it's not where >> the cows are. We owe it to the industry to codify the widespread and >> sufficiently-well-working existing practice. Thanks for your understanding >> of this. >> > > I understand the difficulty here, as breaking changes -- especially at >

Re: [OAUTH-WG] [Technical Errata Reported] RFC6749 (5234)

The term resource owner in the spec is a bit strange but well defined in the front matter of the spec. resource owner An entity capable of granting access to a protected resource. When the resource owner is a person, it is referred to as an end-user. The individual using the

Re: [OAUTH-WG] Device Flow - IPR Disclosure

I am not aware of any IPR. John B. > On Jan 4, 2018, at 10:30 AM, Rifaat Shekh-Yusef wrote: > > Authors, > > As part of the write-up for the Device Flow document, we need an IPR > disclosure from all of you. > > Are you aware of any IPR related to the following Device

Re: [OAUTH-WG] Token scanning attacks in RFC 7662

In reality people developers may not always be putting that much entropy into a token. It is only a SHOULD and hard to enforce. I may have come up with the min entropy number. There may also be side channel attacks if you allow introspection of encrypted or signed tokens. There is also a

Re: [OAUTH-WG] Token Exchange - IPR Disclosure

I am not aware of any IPR on the token exchange document. On Nov 23, 2017 8:14 AM, "Rifaat Shekh-Yusef" wrote: > Authors, > > As part of the write-up for the Token Exchange document, we need an IPR > disclosure from all of you. > > Are you aware of any IPR related to the

Re: [OAUTH-WG] Questions on urn:ietf:wg:oauth:2.0:oob

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

Re: [OAUTH-WG] Recommendations for browser-based apps

Right, Refresh token is bearer for native apps, that is why we came up with PKCE to protect code. For Angular the code flow with PKCE is probably better than the token response type. However with bearer tokens it is still riskier than code with a confidential client so the AS should take

Re: [OAUTH-WG] some implementation feedback with the PKI method of OAuth MTLS client authentication

Having discussed it with Brian, I agree that removing “tls_client_auth_root” is the way to go. It would be hard to implement in some cases, and it is up to the AS to configure the roots it trusts for client authentication. In reality every TLS client auth deployment is likely to have custom

Re: [OAUTH-WG] Redirection in authorization code flow: GET vs POST

his statement. The safest thing > for a client is to only accept POST or other verbs where any kind of > sensitive data is NOT kept in the URL. Sensitive data in URL's leak like a > sieve, even over HTTPS. > Respectfully, > Jim > > > > On 8/11/17 3:18 PM, John Bradley wrote

Re: [OAUTH-WG] Redirection in authorization code flow: GET vs POST

OpenID Connect formally defined a POST response mode. http://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html The OAuth 2 spec docent preclude it. The safest thing for a client is to accept both. The main

Re: [OAUTH-WG] draft-ietf-oauth-closing-redirectors has obsolete header for referer control

This is being rolled in to the broader security documents Torsten and others have been working on. It wouldn’t hurt to update this draft to have the correct referrer policy. Even if it is not progressing, people will still look at it. I will refresh the draft with the change. Thanks, John B.

Re: [OAUTH-WG] draft-ietf-oauth-mtls-03 - auth to other endpoints?

Good point, I don’t think we intended it to be exclusive to the token endpoint. It is another client auth method and should work those other places as well. I will need to look at the other specs to see how they incorporate client auth methods. Thanks John B. > On Aug 7, 2017, at 11:17

Re: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-mtls-03.txt

ient cert, which is better supported? (but will be much more > expensive in terms of CPU time than comparison) > > If an AS registers an x5c with the JWK, is the AS supposed to validate > the x5c signature using the JWK public parameter? Any other checks? > > Thanks, > > Vl

Re: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-mtls-03.txt

>>>> the PKI method and introduced "pub_key_tls_client_auth" for the >>>> Public Key method >>>> o Added implementation considerations, mainly regarding TLS stack >>>> configuration and trust chain validat

Re: [OAUTH-WG] draft-ietf-oauth-closing-redirectors has obsolete header for referer control

Good, so you could send both to be safe without it breaking. John B. > On Aug 3, 2017, at 12:55 PM, Brian Campbell <bcampb...@pingidentity.com> > wrote: > > No, Chrome only shows the error message deep inside the developer tools > console. > > On Thu, Aug 3, 201

Re: [OAUTH-WG] draft-ietf-oauth-closing-redirectors has obsolete header for referer control

ich led me to look up > the changes and content in my original message. > > On Thu, Aug 3, 2017 at 9:35 AM, John Bradley <ve7...@ve7jtb.com > <mailto:ve7...@ve7jtb.com>> wrote: > Brian > > To answer my own question to some extent, this page has support status for >

Re: [OAUTH-WG] draft-ietf-oauth-closing-redirectors has obsolete header for referer control

Brian To answer my own question to some extent, this page has support status for the browsers: http://caniuse.com/#feat=referrer-policy It looks like only FireFox supports strict-origin. Most of them support origin. Some like IE, Opera Mini and older versions of Android (4) don’t support

  1   2   3   4   5   6   7   8   9   >