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

[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

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

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

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

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:

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

thumbprints >> >> >> -- Forwarded message -- >> From: <internet-dra...@ietf.org <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-ann

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

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

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

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

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

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

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 <tors...@lodderstedt.net>

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

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

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

will stop many people 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 Lod

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

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

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

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

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

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

[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 <tors...@lodderstedt.net>, Andrey Labunets <isciu...@fb.com>, John Bradley <ve7...@ve7jtb.com> A new ver

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

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 <michael.jo...@microsoft.com>; oauth@ietf.org *Cc:* gffle...@a

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

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

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

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

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

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

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

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

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

f we can. >> >> — Justin >> >>> On Apr 30, 2016, at 10:57 AM, Torsten Lodderstedt <tors...@lodderstedt.net> >>> wrote: >>> >>> Hi Nat, >>> >>> sure, one could also authenticate and cryptographically protect the >&

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 <tors...@lodderstedt.net <mailto:tors...@lodderstedt.net>> wrote: Hi all, discussion about Mix-Up and CnP s

Re: [OAUTH-WG] State Leakage Attack

il.com>> Gesendet: Saturday, April 23, 2016 10:46 PM An: Torsten Lodderstedt <tors...@lodderstedt.net <mailto:tors...@lodderstedt.net>>,Guido Schmitz <g.schm...@gtrs.de <mailto:g.schm...@gtrs.de>>,oauth@ietf.org <mailto:oauth@ietf.org> Betreff: Re: [OAUTH-WG] St

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 <tors...@lodderstedt.

[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

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

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

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

Re: [OAUTH-WG] OAuth 2.1

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

Re: [OAUTH-WG] OAuth 2.1

ore precisely 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, April 7,

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

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

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

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 > wrote: It's an acceptable fallback option

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

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

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

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

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

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,

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

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

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

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

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 ka...@mit.edu: Hi all, During the shepherd review for draft-ietf-kitten-sasl-oauth-19, I noticed an old comment from Matt

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 sakim...@gmail.com: 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

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

like doing a MiM to intercept the AT or the RS being hacked and leaking the token. Using aud with bearer tokens would be useful, but probably won't stop the majority of possible AT leaks. John B. On Mar 15, 2015, at 2:18 PM, Torsten Lodderstedt tors...@lodderstedt.net wrote: Hi

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

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

Deutsche Telekom also implemented an early version of the draft last year. Am 30.01.2015 um 18:50 schrieb Brian Campbell bcampb...@pingidentity.com: On Tue, Jan 27, 2015 at 9:24 AM, Hannes Tschofenig hannes.tschofe...@gmx.net wrote: 1) What implementations of the spec are you aware

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...@google.com

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

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

Hi John, Am 14.01.2015 um 00:26 schrieb John Bradley ve7...@ve7jtb.com: 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

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 wmills_92...@yahoo.com mailto:wmills_92...@yahoo.com wrote: No other comments on this? Any It's ready to go.? On Monday,

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

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. div Ursprüngliche Nachricht /divdivVon: Nat Sakimura sakim...@gmail.com /divdivDatum:23.10.2014 10:58 (GMT+01:00) /divdivAn: John Bradley

[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 tors...@lodderstedt.net An: kit...@ietf.org Kopie (CC): t...@psaux.com 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

Re: [OAUTH-WG] open redirect in rfc6749

I think a security considerations addendum makes sense. regards,  Torsten.  div Ursprüngliche Nachricht /divdivVon: Richer, Justin P. jric...@mitre.org /divdivDatum:15.09.2014 23:15 (GMT+01:00) /divdivAn: Antonio Sanso asa...@adobe.com /divdivCc: oauth@ietf.org

Re: [OAUTH-WG] OAuth Authentication: What can go wrong?

me too div Ursprüngliche Nachricht /divdivVon: Tirumaleswar Reddy (tireddy) tire...@cisco.com /divdivDatum:12.09.2014 08:50 (GMT+01:00) /divdivAn: Antonio Sanso asa...@adobe.com, Gil Kirkpatrick gil.kirkpatr...@viewds.com /divdivCc: Derek Atkins de...@ihtfp.com,

Re: [OAUTH-WG] Dynamic Client Registration Management Protocol: Next Steps?

+1 div Ursprüngliche Nachricht /divdivVon: John Bradley ve7...@ve7jtb.com /divdivDatum:11.09.2014 02:22 (GMT+01:00) /divdivAn: Mike Jones michael.jo...@microsoft.com /divdivCc: oauth@ietf.org /divdivBetreff: Re: [OAUTH-WG] Dynamic Client Registration Management Protocol:

[OAUTH-WG] Review comments on draft-ietf-oauth-pop-key-distribution-00

Hi John, - new audience header Why do you want to use another header/parameter to identify the target RS? Isn't scope sufficient to carry this information? The text seems to be inconsistent regarding the name (aud or audience) and whether this is actually an header or a parameter. I also miss

Re: [OAUTH-WG] Token revocation endpoint - revoking access token vs. revoking the grant

Hi Pedro, can you please explain the rationale for choosing the mode dynamically? regards, Torsten. Am 11.06.2014 18:20, schrieb Pedro Felix: Hi, In the context of RFC 7009, I've a question regarding revocation of access tokens. I've a scenario where the revocation of an access token may

Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c

+1 the access token is opaque to the client. That's great! Let's keep it that way. Am 05.06.2014 um 21:20 schrieb Bill Mills wmills_92...@yahoo.com: Can't agree more with the peril of overloading auth information into an access token. On Thursday, June 5, 2014 11:05 AM, Mike Jones

Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c

Examples? Am 05.06.2014 um 21:42 schrieb Anthony Nadalin tony...@microsoft.com: It’s great but some ways but also very limiting if you are counting on certain requirements to be represented in the access token From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Torsten Lodderstedt

Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer Shepherd Write-up

Deutsche Telekom also has an implementation.  regards, Torsten. Ursprüngliche Nachricht Von: Chuck Mortimore cmortim...@salesforce.com Datum:25.04.2014 01:31 (GMT+01:00) An: Mike Jones michael.jo...@microsoft.com Cc: oauth@ietf.org Betreff: Re: [OAUTH-WG]

Re: [OAUTH-WG] Working Group Last Call on Dynamic Client Registration Documents

Hi all, I also believe both documents should be merged. Nevertheless, here are my comments on the current drafts: * OAuth 2.0 Dynamic Client Registration Core Protocol http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-16 1.2. Terminology Multiple instances of the same piece of client

Re: [OAUTH-WG] Working Group Last Call on Dynamic Client Registration Documents

PM, Torsten Lodderstedt tors...@lodderstedt.net wrote: Hi Bill, which scalability problem are you referring to? As far as I remember there were issues around the management API but not the core protocol. regards, Torsten. Am 04.04.2014 um 18:41 schrieb Bill Mills wmills_92

Re: [OAUTH-WG] Working Group Last Call on Dynamic Client Registration Documents

Hi Bill, which scalability problem are you referring to? As far as I remember there were issues around the management API but not the core protocol. regards, Torsten. Am 04.04.2014 um 18:41 schrieb Bill Mills wmills_92...@yahoo.com: Given the fundamental scalability problem we discussed in

Re: [OAUTH-WG] Handling stored tokens in mobile app after software update with client credential change

Hi Andre, I would expect the AS to treat a client with a different client id as another client. So the new client should not be able to use the old refresh tokens. Some further questions/remarks: - if you utilize refresh tokens, access tokens should be transient. Right? So you don't need to

Re: [OAUTH-WG] Should data exist for an Oauth access token request to be granted?

Hi Donald,  do you mean data regarding the particular user do not exist (1) at the authorization server or (2) the resource server?  Regards,  Torsten. Ursprüngliche Nachricht Von: Donald Coffin donald.cof...@reminetworks.com Datum:10.02.2014 03:22 (GMT+01:00) An:

Re: [OAUTH-WG] Question on RFC 7009 OAuth 2.0 Token Revocation

of the text doesn't convey that, I don't think. I'd guess the answer is no but does this kind of thing warrant errata consideration? I don't know. I suggest we discuss this in London. best regards, Torsten. On Wed, Jan 8, 2014 at 11:51 AM, Torsten Lodderstedt tors

Re: [OAUTH-WG] Question on RFC 7009 OAuth 2.0 Token Revocation

Hi Brian, this particular sentence is intended to specify the structure of the revocation URL only. It refers to this text in RFC 6749: The endpoint URI MAY include an application/x-www-form-urlencoded formatted (per Appendix B) query component ([RFC3986] Section 3.4), which MUST be

Re: [OAUTH-WG] Scopes in access token response

Hi Pat, out of couriosity: what is the meaning of the refresh_token scope value? regards, Torsten. Pat Patterson ppatter...@salesforce.com schrieb: For what it's worth, we pass back a space-separated list in the response: { id:

Re: [OAUTH-WG] [Editorial Errata Reported] RFC7009 (3808)

Hi all, Charles is right. This reference should be corrected. Regards, Torsten. RFC Errata System rfc-edi...@rfc-editor.org schrieb: The following errata report has been submitted for RFC7009, OAuth 2.0 Token Revocation. -- You may review the report below

Re: [OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-tcse-02.txt

clients. Phil On Nov 9, 2013, at 12:27, Torsten Lodderstedt tors...@lodderstedt.net wrote: Hi, thanks for the explanation. Seems there is the simpler option sufficient to solve the original problem but it's not secure enough to be a general solution. Regarding implementation: The simpler

Re: [OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-tcse-02.txt

client registration + stateless. In my opinion, it's not only broader but easier to use from a client developer's perspective (that's what I care more about than server-side complexity). regards, Torsten. John B. On Nov 10, 2013, at 12:57 AM, Torsten Lodderstedt tors...@lodderstedt.net

Re: [OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-tcse-02.txt

Hi Nat, what's the rationale for having different algorithms to produce a code challenges? As this may cause interop issues there should be good reasons to introduce variants. regards, Torsten. Am 19.10.2013 12:15, schrieb Nat Sakimura: Incorporated the discussion at Berlin meeting and

Re: [OAUTH-WG] IETF WG Follow-up

me too Am 05.11.2013 17:44, schrieb Richer, Justin P.: I'll be there as well. -- Justin On Nov 5, 2013, at 5:34 PM, Phil Hunt phil.h...@oracle.com wrote: I can make it. Phil On Nov 5, 2013, at 16:39, Derek Atkins de...@ihtfp.com wrote: I realize it's short notice but a bunch of us are

Re: [OAUTH-WG] Comments on draft-richer-oauth-introspection-04

Am 25.10.2013 11:19, schrieb Thomas Broyer: On Thu, Oct 24, 2013 at 7:50 AM, Torsten Lodderstedt tors...@lodderstedt.net mailto:tors...@lodderstedt.net wrote: Hi Thomas, we generate access tokens per resource server in order to mitigate this and other risks. You must issue

Re: [OAUTH-WG] Next steps on the OAuth Assertion Drafts

Hi all, here are my comments: --- Assertion Draft --- section 4.1. Authentication of the client is optional, as described in Section 3.2.1 of OAuth 2.0 [RFC6749] and consequently, the client_id is only needed when a form of client authentication that relies on the parameter is used.

Re: [OAUTH-WG] Next Steps for the JSON Web Token Document

No comments - everything is fine Tschofenig, Hannes (NSN - FI/Espoo) hannes.tschofe...@nsn.com schrieb: Hi again, I also checked the minutes from IETF#87 regarding the JWT and here are the action items: ** I issued a WGLC, as discussed during the meeting:

Re: [OAUTH-WG] Dynamic Client Registration Conference Call: Wed 28 Aug, 2pm PDT: Conference Bridge Details

Authz server and resource server need to agree on a token format. The client never needs to interpret the token content. Since we are talking about clients, where is the connection? regards, Torsten. Phil Hunt phil.h...@oracle.com schrieb: I think many of the parameters in dyn reg need to

[OAUTH-WG] Fwd: Re: Dynamic Client Registration Conference Call: Wed 28 Aug, 2pm PDT: Conference Bridge Details

Hi Phil, You would send the client's credential to the authz endpoint, so it would go through the browser and would be exposed to other parties. I agree with George and others. This is a topic different from dyn reg and should be handled independently. I personally consider assertions as

Re: [OAUTH-WG] Dynamic Client Registration Conference Call: Thu 22 Aug, 2pm PDT

trusts. Phil On 2013-08-19, at 22:53, Phil Hunt phil.h...@oracle.com wrote: See below Phil On 2013-08-19, at 22:34, Torsten Lodderstedt tors...@lodderstedt.net wrote: Hi Phil, The assumption that client id must be issued by the sp seems wrong to me in many cases

Re: [OAUTH-WG] Dynamic Client Registration Conference Call: Thu 22 Aug, 2pm PDT

Hi Phil, The assumption that client id must be issued by the sp seems wrong to me in many cases-- including oidc. 6749 does not make this restriction at all. What do you mean? Grant type code requires a client_id in order to identify the client at the AS's authz endpoint. Based on this

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