Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-jwt-introspection-response-00.txt

Hi Neil, > Am 25.05.2018 um 12:49 schrieb Neil Madden : > > Hi Torsten, > >> On 25 May 2018, at 10:35, Torsten Lodderstedt >> wrote: >> >> Hi Neil, >> >>> Am 28.03.2018 um 17:41 schrieb Neil Madden : >>> >>> I like this

Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-jwt-introspection-response-00.txt

tween the > two specifications. > > > Best regards, > Petteri Stenius > > [1] > https://datatracker.ietf.org/meeting/101/materials/slides-101-oauth-sessb-jwt-introspection-response-01 > > > > From: OAuth On Behalf Of Torsten Lodderstedt > Sent:

Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-jwt-introspection-response-00.txt

other than the recipient of the response (or an attacker able to obtain the response object) sets up a fake IDP and provides the response as an ID token to a RP. The RP should be able to detect this (as other ways to replay ID tokens) by utilizing the nonce. kind regards, Torsten. > &g

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-06.txt

: OAuth 2.0 Security Best Current Practice > Authors : Torsten Lodderstedt > John Bradley > Andrey Labunets > Daniel Fett > Filename: draft-ietf-oauth-security-topics-06.t

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

+1 > Am 24.04.2018 um 05:33 schrieb Nat Sakimura : > > +1 > > On Thu, Apr 19, 2018 at 3:28 AM Richard Backman, Annabelle > mailto:richa...@amazon.com>> wrote: > I support adoption of OAuth 2.0 Incremental Authorization as a WG document. > > > > -- > > Annabelle Richard Backman > > Amazon

Re: [OAUTH-WG] scp claim in draft-ietf-oauth-token-exchange-12

Behalf Of Brian Campbell > Sent: Wednesday, April 18, 2018 8:17 AM > To: Torsten Lodderstedt > Cc: oauth > Subject: Re: [OAUTH-WG] scp claim in draft-ietf-oauth-token-exchange-12 > > The draft-ietf-oauth-token-exchange document makes use of scope and at some > point in

Re: [OAUTH-WG] Comments on draft-ietf-oauth-security-topics-05

Hi Phil, thanks for reviewing it. We incorporated the respective changes in the upcoming -06. best regards, Torsten. > Am 22.03.2018 um 10:52 schrieb Phil Hunt : > > Torsten, > > Great document! > > Some minor nits and comments: > > Abstract - double period after first sentence. > >> It

[OAUTH-WG] scp claim in draft-ietf-oauth-token-exchange-12

Hi all, I I’m wondering why draft-ietf-oauth-token-exchange-12 defines a claim „scp“ to carry scope values while RFC 7591 and RFC 7662 use a claim „scope“ for the same purpose. As far as I understand the text, the intension is to represent a list of RFC6749 scopes. Is this correct? What’s the r

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-05.txt

Hi all, thanks for your feedback. Here is my text proposal for section 3.8.1. —— Attackers could try to utilize a user's trust in the authorization server (and its URL in particular) for performing phishing attacks. RFC 6749 already prevents open redirects by stating the AS MUST NOT automa

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-05.txt

Hi Brian, > Am 20.03.2018 um 15:37 schrieb Brian Campbell : > > +1 to what Travis said about 3.8.1 > > The text in 3.8 about Open Redirection is new in this most recent -05 version > of the draft so this is really the first time it's been reviewed. I believe > 3.8..1 goes too far in saying "th

Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-jwt-introspection-response-00.txt

ment in a more generic way ? >> >> Regards, >> Louis >> >> De : OAuth mailto:oauth-boun...@ietf.org>> De la >> part de Brock Allen >> Envoyé : dimanche 18 mars 2018 20:40 >> À : Torsten Lodderstedt > <mailto:tors...@lodderst

Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-jwt-introspection-response-00.txt

> > -Brock > >> On 3/18/2018 3:33:16 PM, Torsten Lodderstedt wrote: >> >> Hi all, >> >> I just submitted a new draft that Vladimir Dzhuvinov and I have written. It >> proposes a JWT-based response type for Token Introspection. The objective is

[OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-jwt-introspection-response-00.txt

8. März 2018 um 20:19:37 MEZ > An: "Vladimir Dzhuvinov" , "Torsten Lodderstedt" > > > > A new version of I-D, > draft-lodderstedt-oauth-jwt-introspection-response-00.txt > has been successfully submitted by Torsten Lodderstedt and posted to the > I

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-05.txt

ecurity Best Current Practice > Authors : Torsten Lodderstedt > John Bradley > Andrey Labunets > Filename: draft-ietf-oauth-security-topics-05.txt > Pages : 27 > Date: 2018-0

Re: [OAUTH-WG] IETF101 Draft Agenda

, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015. [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7516, May 2015. [OpenID.Registration] NRIPing IdentityMicrosoft, "OpenID Connect Dynamic Client Reg

Re: [OAUTH-WG] IETF101 Draft Agenda

Can you please add the security topics to the agenda for Wednesday? I will publish -05 soon and I support your proposal to talk about a consensus call. Thanks, Torsten. > Am 07.03.2018 um 19:53 schrieb Rifaat Shekh-Yusef : > > Here is the draft agenda for our two sessions: > > Monday > htt

[OAUTH-WG] Token Introspection and JWTs

Hi all, I have an use case where I would like to return signed JWTs from the authorization server’s introspection endpoint. In this case, I would like to give the resource server evidence about the fact the AS minted the access token and is liable for its contents (verified person data used to

[OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-security-topics-04.txt

ol WG of the IETF. > >Title : OAuth Security Topics >Authors : Torsten Lodderstedt > John Bradley > Andrey Labunets > Filename: draft-ietf-oauth-security-topics-04.txt > Pages

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

> Am 09.11.2017 um 04:42 schrieb Brian Campbell : > > There is no special reason for the > "mutual_tls_sender_constrained_access_tokens" name that I'm aware of. I > believe Torsten chose the name and based it off of language in the draft. > While "certificate_bound_access_tokens" does sound so

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

ries. > This draft is a work item of the Web Authorization Protocol WG of the IETF. > >Title : OAuth Security Topics > Authors : Torsten Lodderstedt > John Bradley > Andrey Labunets > F

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

+1 for removing tls_client_auth_root > Am 28.08.2017 um 20:24 schrieb John Bradley : > > 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 fo

Re: [OAUTH-WG] How could an IdP create an id token for one audience RP without knowing for which RP ?

+1 > Am 31.07.2017 um 16:01 schrieb John Bradley : > > For access tokens I would like to see a use case for a completely = > decoupled and anonymous RS that is not just a misuse of OAuth for = > Authentication, before trying to add a feature like this. smime.p7s Description: S/MIME cryptographi

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

>> From: mailto:internet-dra...@ietf.org>> >> Date: Fri, Jul 28, 2017 at 12:25 PM >> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-03.txt >> To: i-d-annou...@ietf.org <mailto:i-d-annou...@ietf.org> >> Cc: oauth@ietf.org <mailto:oauth@ietf.org&

Re: [OAUTH-WG] Agenda requests for Prague

Hi, I would like to give an update on our work on draft-ietf-oauth-security-topics (mainly access token leakage at the RS). 10 min should be suffice. Please note: I won’t be able to present on Friday. Please consider to assign me/us a slot in the Tuesday session. Thanks, Torsten. Am 29.06.20

Re: [OAUTH-WG] Call for Participation: Second OAuth Security Workshop

Correction: the workshop takes place July 13-14 > Am 29.05.2017 um 09:11 schrieb Torsten Lodderstedt : > > === > > C a l l F o r P a r t i c i p a t i o n > > Second OAuth Securi

[OAUTH-WG] Call for Participation: Second OAuth Security Workshop

-workshop-2017/ Important Dates Registration deadline: June 16, 2017. Workshop: July 10 and July 11, 2017. Invited Speakers Cas Cremers, University of Oxford Program Committee Chairs David Basin (ETH Zurich) Torsten Lodderstedt (YES Europe) Members John Bradley (Ping Identity) Ralf Küsters

[OAUTH-WG] ZISC OAuth Security Workshop at ETH Zurich on July 13+14

The Zurich Information Security and Privacy Center (ZISC) is hosting the OAuth Security Workshop on July 13+14 at ETH Zurich, Switzerland. The main theme is the security of OAuth, but there are also talks about OpenID Connect and other related technologies. You can find more information, includi

Re: [OAUTH-WG] Phishing with Client Application Name Spoofing

two days can last for a very long time ;-) I will add this threat to the list to be covered by our new security draft. > Am 10.05.2017 um 23:15 schrieb André DeMarre : > > I see there is a new security considerations document being drafted. There is > an old issue that I've recently been remind

Re: [OAUTH-WG] New OAuth client credentials RPK and PSK

Hi Samuel, as far as I understand your draft, it utilizes results of the (D)TLS client authentication for authentication towards the tokens endpoint - similar to https://tools.ietf.org/html/draft-ietf-oauth-mtls-00.html. Do you intend to also utilize the binding of the access token to a certain

Re: [OAUTH-WG] Second OAuth Security Workshop (Call for Papers)

topic. best regards, Torsten. > Am 20.04.2017 um 19:49 schrieb Mike Jones : > > Excellent! >   <> > From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] > Sent: Thursday, April 20, 2017 10:42 AM > To: oauth@ietf.org > Cc: Mike Jones ; John Bradley > Sub

Re: [OAUTH-WG] Second OAuth Security Workshop (Call for Papers)

1) Can you handle remote participants? > 2) Any chance you want to move this to Hawaii? I can host the work space. > Seriously. > > Aloha, > -- > Jim Manico > @Manicode > >> On Apr 20, 2017, at 7:42 PM, Torsten Lodderstedt >> wrote: >> >> Hi all, &

Re: [OAUTH-WG] OAuth 2.0 Device Flow: IETF98 Follow-up

+1 to keep the optional parameter along with clear wording regarding security risk and interoperability > Am 29.04.2017 um 15:12 schrieb Justin Richer : > > +1, documentation is better. Though we also need to keep in mind that this > was the justification for the password flow in 6749, which h

Re: [OAUTH-WG] Call for Adoption: Mutual TLS Profiles for OAuth Clients

+1 for adoption > Am 21.04.2017 um 21:43 schrieb Nat Sakimura : > > +1 for adoption > > On Apr 21, 2017 9:32 PM, "Dave Tonge" > wrote: > I support adoption of draft-campbell-oauth-mtls > > As previously mentioned this spec will be very useful for Europe wher

Re: [OAUTH-WG] Second OAuth Security Workshop (Call for Papers)

ple from being > able to attend including myself unless I can come up with other meetings in > Europe to fill those days. > > If we cant move it then we will have to live with it and attend or not. > > John B. > >> On Mar 13, 2017, at 4:46 PM, Torsten Lodderstedt >

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-13.txt

I had assumed using the request object is mutual exclusive to use of URI query parameters. Did I misinterpret the draft? > Am 30.03.2017 um 22:40 schrieb John Bradley : > > It is a trade off between compatibility with Connect and possible > configuration errors. > > In reality it may not be c

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-07.txt

or resources. > >Thanks, >-- Mike >   <> > From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell > Sent: Monday, March 27, 2017 8:45 AM > To: Torsten Lodderstedt > Cc: oauth > Subject: Re:

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-07.txt

Hi Brian, thanks for the clarification around resource, audience and scope. Here are my comments on the draft: In section 2.1 it states: „Multiple "resource" parameters may be used to indicate that the issued token is intended to be used at the multiple resources listed.“ Can you

Re: [OAUTH-WG] OAuth Agenda

Hi Hannes, I had asked for 5 minutes on Monday (because I want to raise awareness with respect of the security draft). Would it be possible to adjust the agenda accordingly? kind regards, Torsten (w/o „h“). > Am 21.03.2017 um 15:47 schrieb Hannes Tschofenig : > > Here is the latest snapshot o

Re: [OAUTH-WG] oauth - Requested sessions have been scheduled for IETF 98

Hi Chairs, I would like to request 5 minutes on Monday to briefly present the status of the security document. This is mainly to raise awareness in the group since I didn’t get that much input on it since Seoul. kind regards, Torsten. > Am 18.03.2017 um 01:52 schrieb Mike Jones : > > Hi Chair

Re: [OAUTH-WG] Second OAuth Security Workshop (Call for Papers)

t people > should also be considering attending? > > Thanks, > -- Mike > > -Original Message- > From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Torsten Lodderstedt > Sent: Sunday, March 12, 2017 12:28 PM > To: oauth@iet

[OAUTH-WG] Second OAuth Security Workshop (Call for Papers)

revise their papers before they are put online. IPR Policy The workshop will have no expectation of IPR disclosure or licensing related to its submissions. Authors are responsible for obtaining appropriate publication clearances. Program Committee Chairs David Basin (ETH Zurich) Torsten

Re: [OAUTH-WG] Conclusion of 'OAuth Security Topics' Call for Adoption

Hi Hannes, just for clarification: as far as I remember the proposal in Seoul was to turn the document into a BCP. Is this consistent with your expectation? kind regards, Torsten. > Am 20.02.2017 um 12:02 schrieb Hannes Tschofenig : > > Hi all, > > earlier this month we issued a call for ad

Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app

+1 > Am 25.01.2017 um 21:32 schrieb Phil Hunt (IDM) : > > +1 to AppAuth > > One disturbing pattern I see for mobile apps relaying the idtoken is that the > aud isn't checked by the AS in the Oauth exchange. This in part caused by the > fact that the mobile app has two client-id identifiers. If

[OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-security-topics-00.txt

Version Notification for draft-lodderstedt-oauth-security-topics-00.txt Datum: Sun, 13 Nov 2016 07:02:04 -0800 Von:internet-dra...@ietf.org An: Torsten Lodderstedt , Andrey Labunets , John Bradley A new version of I-D, draft-lodderstedt-oauth-security-topics-00.txt has been successfully

Re: [OAUTH-WG] Comments on draft-jones-oauth-resource-metadata-00

nable semantics tied to it and its existence only encourages confusion. Thanks for reading the draft, Torsten. -- Mike *From:*Torsten Lodderstedt [mailto:tors...@lodderstedt.net] *Sent:* Sunday, November 13, 2016 2:32 PM *To:* Mike Jones ; oauth@ietf.org *Cc:* gffle...@aol.com *Subject:

Re: [OAUTH-WG] Using Referred Token Binding ID for Token Binding of Access Tokens

-06#section-2 where it talks about a Sec-Token-Binding Header Field with a TokenBindingMessage with a TokenBinding structure with TokenBindingType of referred_token_binding. The example is a good idea. -- Mike *From:*Torsten Lodderstedt [mailto:tors...@lodderstedt.net] *Sent:* Sunday, November

Re: [OAUTH-WG] OAuth: the ABC attack (the Alice and Bob Collusion attack)

I agree, we should analyse the threat. From my first impression it feels like injection with some specialties. @Denis: So far, I'm struggeling to understand how this attack is performed from a practical perspective. Every token/assertion issued to the uncle is bound to its identity. So it the

Re: [OAUTH-WG] New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt

r not. We don’t let clients switch away from their registered auth mechanism. — Justin On Nov 13, 2016, at 2:21 PM, Torsten Lodderstedt mailto:tors...@lodderstedt.net>> wrote: Justin, Am 13.11.2016 um 13:39 schrieb Justin Richer: Torsten, I believe this is intended to be trigg

Re: [OAUTH-WG] Using Referred Token Binding ID for Token Binding of Access Tokens

Hi Mike, does this mean the binding ID is indicated to the authorization server via a respective HTTP header? I'm asking because I didn't find the respective parameter in the draft. Could you add a HTTP request example? I think that would help a lot to better understand the mechanism. best

Re: [OAUTH-WG] Comments on draft-jones-oauth-resource-metadata-00

Hi Mike, just read your spec and I'm also a bit confused about the "resource" meta data element in section 2. I would assume the metadata are provided for a certain resource server managing a set of resources in a particular administrative domain. So I would prefer to name the respective ele

Re: [OAUTH-WG] New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt

_supported version is from the corresponding discovery document. — Justin Torsten. On Nov 13, 2016, at 12:31 PM, Torsten Lodderstedt mailto:tors...@lodderstedt.net>> wrote: Hi John and Brian, thanks for writting this draft. One question: how does the AS determine the authentication method i

Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt

Hi John and Brian, thanks for writting this draft. One question: how does the AS determine the authentication method is TLS authentication? I think you assume this is defined by the client-specific policy, independent of whether the client is registered automatically or manually. Would you mi

Re: [OAUTH-WG] Agenda

Hi Hannes, I would like to present and discuss the OAuth Security draft I'm working on (with John and Andrey). Can you please reserve 15 min in the Wednesday session? I plan to publish the draft after the IETF submission tool has re-opened. best regards, Torsten. Am 06.11.2016 um 12:42 schr

Re: [OAUTH-WG] Call for adoption: Token Binding for OAuth 2.0

+1 I would also propose to focus use of token binding to detect replay of tokens (access, refresh, code) Am 22.08.2016 um 23:02 schrieb Brian Campbell: I agree with Tony, if I understand what he's saying. https://tools.ietf.org/html/draft-campbell-oauth-tbpkce-00

Re: [OAUTH-WG] OAuth Metadata Specifications Enhanced

It does not adress the relationship between resource and scope. Am 04.08.2016 22:12, schrieb John Bradley: This was proposed https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-01 It seemed to be a bit too controversial for the WG to accept at the time it was discussed. Joh

Re: [OAUTH-WG] Call for adoption: Token Binding for OAuth 2.0

+1 Am 17.08.2016 09:39, schrieb Dirk Balfanz: On Wed, Aug 3, 2016 at 1:48 PM John Bradley > wrote: I accept these documents as a starting point of the Token binding work in OAuth. Same here. I accept adoption as a starting point. Dirk. John B. >

Re: [OAUTH-WG] Working Group Last Call on "OAuth 2.0 for Native Apps"

Hi, generally, I considers this a highly valuable contribution and support to move it forward. Some nits: section 7.3, last paragraph: "... as it is less susceptible to misconfigured routing and client side firewalls Note ..." - I think a period is missing between "firewalls" and "Note" p

Re: [OAUTH-WG] Mix-Up and CnP/ Code injection

n Richer wrote: >> I agree that we’re getting dangerously close to recommending signed >> assertions at every step of the process, thereby bypassing HTTP. This was >> the same mistake that WS-* and SOAP made, let’s not repeat it if we can. >> >> — Justin

Re: [OAUTH-WG] Mix-Up and CnP/ Code injection

have to authenticate response. ID Token was designed to also serve as a solution anticipating it. Any concrete ideas? On Sat, Apr 23, 2016 at 04:47 Torsten Lodderstedt mailto:tors...@lodderstedt.net>> wrote: Hi all, discussion about Mix-Up and CnP seems to have stopped aft

Re: [OAUTH-WG] State Leakage Attack

aturday, April 23, 2016 10:46 PM An: Torsten Lodderstedt <mailto:tors...@lodderstedt.net>>,Guido Schmitz <mailto:g.schm...@gtrs.de>>,oauth@ietf.org <mailto:oauth@ietf.org> Betreff: Re: [OAUTH-WG] State Leakage Attack On Sat, Apr 23, 2016 at 3:56 PM Torsten Lodderstedt mailto

Re: [OAUTH-WG] State Leakage Attack

I don't think this is possible if the client checks whether the state actually belongs to its local session before it processes it. Everything else seems weird. Am 23.04.2016 um 15:53 schrieb Thomas Broyer: On Sat, Apr 23, 2016 at 12:57 PM Torsten Lodderstedt mailto:tors...@loddersted

[OAUTH-WG] Mix-Up and CnP/ Code injection

Hi all, discussion about Mix-Up and CnP seems to have stopped after the session in BA - at least in the OAuth WG. There is a discussion about mitigations in OpenId Connect going on at the OpenId Connect mailing list. I'm very much interested to find a solution within the OAuth realm as I'm n

Re: [OAUTH-WG] State Leakage Attack

Hi Guido, do I get it right. The attacker is supposed to use the state value in order to overwrite the user agent's session state? best regards, Torsten. Am 23.04.2016 um 12:47 schrieb Guido Schmitz: Hi Torsten, as the state value is supposed to protect the user agent's session against CSRF

Re: [OAUTH-WG] Meeting Minutes

Hi all, the security discussion started with mix up and cut and paste, but we had a much broader discussion including further issues, such as open redirector. I suggested to merge all threats we are currently discussing into a single document in order to come up with a consolidated view on "enh

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

Indicating the resource server to the AS allows the AS to automatically select token type, encryption scheme and user data to be put into the access token based on a RS-specific policy. So there is no need to explicitely ask the AS for a certain token format or encryption scheme. > Am 11.04.20

Re: [OAUTH-WG] OAuth 2.1

not seeing the reason why scopes need >> to be defined, as these are application specific. >> >> -Original Message- >> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Torsten >> Lodderstedt >> Sent: Thursday, April 7, 2016 5:32 AM >> To: George F

Re: [OAUTH-WG] OAuth 2.1

ly as this > opaqueness was a design feature, I'm not seeing the reason why scopes need to > be defined, as these are application specific. > > -Original Message----- > From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Torsten Lodderstedt > Sent: Thursday, Ap

Re: [OAUTH-WG] OAuth 2.1

Hi all, as I already said in the meeting: I would very much prefer to have an extension/update of RFC 6819 covering all "new" threats, including: - mix up - code injection aka copy and paste - open redirector at AS and client - potential other threats in the context of "dynamic" OAuth I also ass

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) is now RFC 7800

Congratulations! And what an RFC number ;-) > Am 06.04.2016 um 23:14 schrieb Mike Jones : > > The Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) > specification is now RFC 7800 – an IETF standard. The abstract describes the > specification as: > > This specification describes ho

Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-resource-indicators-01.txt

Hi Brian, did you intentionally omit scope values in your example requests? I would like to know what you envision to be the relationshop between scope and resource. As you draft says, we today use scope values to indicate to the AS, which ressource servers the clients wants to access. I think

Re: [OAUTH-WG] RFC 7009: Revoke Access Tokens issued to HTML5 web apps

Hi Thomas, see comments inline. Am 19.02.2016 um 12:14 schrieb thomas.ku...@bmw.de: Hi, we use the OAuth 2.0 Implicit grant to issue access_tokens to client applications such as HTML 5 web apps that have no secure means to securely authenticating themselves. Even if the credentials would be

Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption

Hi all, I prefer to use draft-jones-oauth-mix-up-mitigation-01 as starting point simply because it gives some description of the threats we need to cope with. This does not preclude to eventually use draft-sakimura-oauth-meta-07 as solution or any other suitable mechanisms we find consensus o

Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized

Hi Denniss, out of curiosity: Does Google use amr values? best regards, Torsten. Am 14.02.2016 um 02:40 schrieb William Denniss: On Sat, Feb 13, 2016 at 12:19 PM, Mike Jones mailto:michael.jo...@microsoft.com>> wrote: It's an acceptable fallback option if the working group decides it

Re: [OAUTH-WG] Call for Adoption: Stateless Client Identifier for OAuth 2

+1 Am 04.02.2016 um 17:37 schrieb John Bradley: I support it. I have always thought of this as informational. It is not the only way to do it, and has no real interoperability impact. John B. On Feb 4, 2016, at 3:29 AM, Mike Jones wrote: I support adoption of this document by the working

Re: [OAUTH-WG] OAuth 2.0 Device Flow: Call for Adoption Finalized

I support adoption of this draft as starting point. I would like to note the following: - this flow is vulnerable to session fixation - A discussion of this threat along with a reasonable mitigation needs to be added. - I dont't understand why this particular flow precludes use of client secret

Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation: My Impressions

Hi Hannes, #2 is not directly described in the paper but was used to replay the code/token the attacker obtained via #1. In my observation, the discussion in Darmstadt has shown that OAuth (and its built-in mitigations) so far focused on preventing code/token leakage but we lake mitigation fo

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

I think the service discovery document (describing all the endpoints and features of the AS) is a valid starting point. That's basically how we use the OIDC discovery in the OAuth context today at DT. We refer partners to the openid-configuration document. Putting the data relevant to OAuth und

Re: [OAUTH-WG] OAuth Discovery metadata values added for revocation, introspection, and PKCE

cation and introspection is "bearer_token", since it makes sense in both cases to give a client an access token to call these endpoints as opposed to credentials. This would need to be added to the token endpoint authentication methods registry. -- Justin On 1/31/2016 7:13 AM, Torsten Lo

Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Draft

Hi Mike, I really like the new revision since it is much simpler :-) My comments: I'm fine with describing all mitigations we talked about in Darmstadt in one/this spec. But the state check at the tokens endpoint is supposed to be a mitigation against code injection/cut and paste attack, whic

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

Hi, I support the adoption of this document as starting point for our work towards OAuth discovery. Restating what I already posted after the last IETF meeting: It seems the document assumes the AS can always be discoverd using the user id of the resource owner. I think the underlying assump

Re: [OAUTH-WG] Advertise PKCE support in OAuth 2.0 Discovery (draft-jones-oauth-discovery-00)

+1 Am 06.01.2016 um 18:25 schrieb William Denniss: +1 On Wed, Jan 6, 2016 at 6:40 AM, John Bradley > wrote: Good point. Now that PKCE is a RFC we should add it to discovery. John B. > On Jan 6, 2016, at 9:29 AM, Vladimir Dzhuvinov mailto:vladi...@co

Re: [OAUTH-WG] OAuth Discovery

Hi Mike, Nat, John, thanks for starting this work. It seems you assume the AS can always be discoverd using the user id of the resource owner. I think the underlying assumption is resource servers accept access token of different (any?) user specific AS (and OP)? From my perspective, RSs nowa

Re: [OAUTH-WG] Fwd: RFC 7628 on A Set of Simple Authentication and Security Layer (SASL) Mechanisms for OAuth

+1 Am 1. September 2015 17:44:12 MESZ, schrieb Mike Jones : >Congratulations, Bill! > >-Original Message- >From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt >Sent: Tuesday, September 01, 2015 8:14 AM >To: Hannes Tschofenig >Cc: oauth@ietf.org >Subject: Re: [OAUTH-WG] Fwd:

Re: [OAUTH-WG] Lifetime of refresh token

Refresh tokens are also used by public clients, e.g. native apps. OIDC allows to acquire a new id token from a refresh token as well. Note: this does not mean a fresh authentication but a refreshed id token containing the data of the original authentication transaction. Am 24. August 2015 17:0

Re: [OAUTH-WG] minor issue with scope and RFC 6749 ABNF in sasl-oauth

Hi Benjamin, in my opinion, your proposal sound reasonable from a protocol perspective. kind regards, Torsten. Am 23. März 2015 06:26:20 MEZ, schrieb Benjamin Kaduk : >Hi all, > >During the shepherd review for draft-ietf-kitten-sasl-oauth-19, I >noticed >an old comment from Matt back in Dec

Re: [OAUTH-WG] The use of sub in POP-02

+1 sounds reasonable to distinguish the software and the user. Am 23. März 2015 08:25:13 MEZ, schrieb Nat Sakimura : >Re: >https://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-02#section-3 > >I understand the use of sub in this section comes down from SAML but I >feel >that some separ

Re: [OAUTH-WG] Standard URL parameter for mitigating RFC6819's threat 4.6.4?

>>> >>> I don't know of any clients that would try to access a RS server and then >>> besed on the error response try and get a access token from the AS >>> specified in the error. >>> >>> In POP we are trying to both protect agains tha

Re: [OAUTH-WG] Standard URL parameter for mitigating RFC6819's threat 4.6.4?

Hi Josh, I'm not aware of a common practice to use such a parameter. The WG is instead heading towards authenticated requests to the resource server (see https://tools.ietf.org/html/rfc6819#section-5.4.2). Please take a look onto http://tools.ietf.org/html/draft-ietf-oauth-pop-architecture a

Re: [OAUTH-WG] draft-ietf-oauth-spop-10: Your feedback needed.

Hi Hannes, Am 02.03.2015 um 16:31 schrieb Hannes Tschofenig: Hi all, I am trying to finalize my work on the shepherd write-up of draft-ietf-oauth-spop. Unfortunately, there are still some outstanding issues: 1. S256 as a mandatory-to-implement code challenge method (by the Authorization Serve

Re: [OAUTH-WG] [Editorial Errata Reported] RFC6819 (4267)

Hi all, @David: Thanks for reporting this issue. Mark, Phil and I discussed the errata and came to the following conclusion: The introduction is correct because this section is about "DoS Attacks That Exhaust Resources" caused by the fact that the AS creates a nontrivial amount of entropy for

Re: [OAUTH-WG] Shepherd Writeup for draft-ietf-oauth-spop-06.txt

the >> > code verifier. >> > >> > kind regards, >> > Torsten. >> > >> > Am 17.02.2015 17:48, schrieb Hannes Tschofenig: >> >> Hi Torsten, >> >> >> >> does this mean that you

Re: [OAUTH-WG] Shepherd Writeup for draft-ietf-oauth-spop-06.txt

Deutsche Telekom also implemented an early version of the draft last year. > Am 30.01.2015 um 18:50 schrieb Brian Campbell : > > >> On Tue, Jan 27, 2015 at 9:24 AM, Hannes Tschofenig >> wrote: >> >> 1) What implementations of the spec are you aware of? > > We have an AS side implementation

Re: [OAUTH-WG] RFC 7009 OAuth 2.0 Token Revocation //proposed change wrt to "default" revocation of refresh tokens

<mailto:oauth@ietf.org>? or a specific working group email? Thanks again for your response. -- Thanks Amit *From:*Torsten Lodderstedt [mailto:tors...@lodderstedt.net] *Sent:* Sunday, January 18, 2015 2:11 PM *To:* Amit Gupta *Cc:* Justin Richer; sdro...@gmx.de; oauth@ietf.org; mscurte...@goog

Re: [OAUTH-WG] RFC 7009 OAuth 2.0 Token Revocation //proposed change wrt to "default" revocation of refresh tokens

Hi Amit, as far as I understand you are asking for a documentation of guidelines for refresh token lifecycle management. Such guidlines are not in scope for RFC 7009, as it only wants to add a request to the AS to give the client an (interoperable) way to explicitly revoke tokens. Tokens lifecy

Re: [OAUTH-WG] oauth-pop-key-distribution

Hi John, > Am 14.01.2015 um 00:26 schrieb John Bradley : > > We don't currently have any examples in the spec of getting a key based on a > RT but it is required if you are using symmetric keys with multiple RS. I think one could treat RTs like any other tokens in pop and issue a corresponding

Re: [OAUTH-WG] Fwd: [kitten] WGLC of draft-ietf-kitten-sasl-oauth-18

I think the document is ready to go. Am 29.12.2014 um 19:00 schrieb Jamie Nicolson (倪志明): Still looks good to me. On Mon, Dec 29, 2014 at 11:46 AM, Bill Mills > wrote: No other comments on this? Any "It's ready to go."? On Monday, December 15, 2014 9:

Re: [OAUTH-WG] Notes from 2nd "OAuth & Authentication" Conference Call

Hi all, I just read the document. It explains the situation, challenges/threats, and options very clear and readable. So +1 for publishing it soon. kind regards, Torsten. Am 28.10.2014 00:21, schrieb Richer, Justin P.: I've been incorporating peoples' feedback into the proposed oauth.net pa

Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT)

+1 Delegating security to the transport layer is a common pattern. "None" should be MTI otherwise I expect a lot of interop issues. Ursprüngliche Nachricht Von: Nat Sakimura Datum:23.10.2014 10:58 (GMT+01:00) An: John Bradley Cc: The IESG , oauth@ietf.org, oauth-cha...@to

[OAUTH-WG] Fwd: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-16.txt

: Sat, 11 Oct 2014 13:30:48 +0200 Von:Torsten Lodderstedt An: kit...@ietf.org Kopie (CC): t...@psaux.com Hi all, as one of the proposers (beside Hannes) of the change, I would like to explain the rationale. -16 is submitted, and there is one suggested change (which I was supposed

Re: [OAUTH-WG] open redirect in rfc6749

I think a security considerations addendum makes sense. regards,  Torsten.  Ursprüngliche Nachricht Von: "Richer, Justin P." Datum:15.09.2014 23:15 (GMT+01:00) An: Antonio Sanso Cc: oauth@ietf.org Betreff: Re: [OAUTH-WG] open redirect in rfc6749 As we discussed before: Th

<    1   2   3   4   5   6   7   8   9   10   >