Re: [OAUTH-WG] updated Distributed OAuth ID

ed UX. > > Am 24.07.2018 um 22:21 schrieb Dick Hardt : > > I'm trying to understand the use case. > > It still is vague. Are you saying that each of these is run by a > different entity, but all trust the bank as the authorization server to > manage if the user has granted pe

Re: [OAUTH-WG] updated Distributed OAuth ID

y are you asking? > > > On Mon, Jul 23, 2018 at 12:50 PM, Torsten Lodderstedt < > tors...@lodderstedt.net> wrote: > >> >> Am 23.07.2018 um 13:58 schrieb Dick Hardt : >> >> In your examples, are these the same AS? >> >> >> yes >>

Re: [OAUTH-WG] updated Distributed OAuth ID

And who is the AS? On Mon, Jul 23, 2018 at 12:50 PM, Torsten Lodderstedt < tors...@lodderstedt.net> wrote: > > Am 23.07.2018 um 13:58 schrieb Dick Hardt : > > In your examples, are these the same AS? > > > yes > > > > > On Mon, Jul 23, 20

Re: [OAUTH-WG] updated Distributed OAuth ID

In your examples, are these the same AS? On Mon, Jul 23, 2018 at 3:42 AM Torsten Lodderstedt wrote: > Hi Dick, > > > Am 23.07.2018 um 00:52 schrieb Dick Hardt : > > > > Entering in an email address that resolves to a resource makes sense. It > would seem that even

Re: [OAUTH-WG] updated Distributed OAuth ID

On Sat, Jul 21, 2018 at 12:49 PM, Torsten Lodderstedt < tors...@lodderstedt.net> wrote: > Hi Dick, > > Am 19.07.2018 um 15:46 schrieb Dick Hardt : > > I think any scenario with multiple resource servers relying on the same AS >> for authorization where the client act

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

There are a few places where multiple resources could be used: One is in the code flow where it is desirable to optimize the user experience so that the user is granting authorization once, and not multiple times. The second is in the access token request, which leads to the third instance,

Re: [OAUTH-WG] Call for adoption for "Distributed OAuth"

I'm supportive. :) On Thu, Jul 19, 2018 at 4:05 PM, Rifaat Shekh-Yusef wrote: > Hi all, > > This is the call for adoption of the 'Distributed OAuth' document > following the positive call for adoption at the Montreal IETF meeting. > > Here is the document: >

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

William: there was discussion in the meeting about the PoP document using "resource" rather than "aud" On Thu, Jul 19, 2018 at 4:53 PM, Mike Jones < Michael.Jones=40microsoft@dmarc.ietf.org> wrote: > Microsoft’s Azure AD OAuth server has used the resource= parameter since > at least 2012 to

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

I support adoption of this document. On Thu, Jul 19, 2018 at 4:54 PM, John Bradley wrote: > > > I accept the adoption of this document. > > > > Sent from Mail for > Windows 10 > > > > *From: *Rifaat Shekh-Yusef > *Sent: *Thursday, July 19, 2018

Re: [OAUTH-WG] updated Distributed OAuth ID

On Thu, Jul 19, 2018 at 8:51 AM, Torsten Lodderstedt < tors...@lodderstedt.net> wrote: > Hi Dick, > > > >> >> Section 3: >> Don’t you think it could be a useful information to have the resource URI >> available in the authorization flow?I would assume it could have some >> additional meaning to

Re: [OAUTH-WG] updated Distributed OAuth ID

consumed within an > origin. This would actually make redundant/supplemental the AS additions > defined within this spec (resource/origin request parameter, ‘aud’ > introspection response member) > Token binding solves part of the resource constrained access token requirement, but

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-reciprocal-00.txt

nd. > > Regards, > Rifaat > > > On Tue, Jul 17, 2018 at 12:01 PM Dick Hardt wrote: > >> Thanks for the review Torsten. All good points to be clarified in the >> doc. Responses inserted ... >> >> On Tue, Jul 17, 2018 at 11:22 AM, Torsten Lodderstedt &l

Re: [OAUTH-WG] updated Distributed OAuth ID

i-service deployments.. > It could be. Would be great to get some real use cases for that in an Authorization Code Grant. > > Section 6.1. > I suggest you also refer to https://tools.ietf.org/html/ > draft-ietf-oauth-security-topics-06#section-3.7 for a comprehensive > discussion of this

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-reciprocal-00.txt

lp. > > kind regards, > Torsten. > > > Am 24.05.2018 um 22:28 schrieb internet-dra...@ietf.org: > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Web Authorization Protocol WG of the &

Re: [OAUTH-WG] IPR confirmation for draft-ietf-oauth-jwt-bcp-03

Confirmed, thanks. On Tue, Jul 17, 2018 at 9:35 AM Hannes Tschofenig wrote: > Hi Yaron, Dick, Mike, > > > > Please confirm that any and all appropriate IPR disclosures required for > full conformance with the provisions of BCP 78 and BCP 79 have already been > filed for

Re: [OAUTH-WG] OAuth WG draft agenda

Besides being the oddness that session I happens after session II ... looks ok! On Mon, Jul 9, 2018 at 7:42 AM, Rifaat Shekh-Yusef wrote: > The following is a draft agenda for next week. > Please, let us know if you have any comments. > > Regards, > Rifaat & Hannes > > > Web Authorization

[OAUTH-WG] updated Distributed OAuth ID

Hey OAuth WG I have worked with Nat and Brian to merge our concepts and those are captured in the updated draft. https://datatracker.ietf.org/doc/draft-hardt-oauth-distributed/ We are hopeful the WG will adopt this draft as a WG document. Any comments and feedback are welcome! /Dick

Re: [OAUTH-WG] Call for Adoption: Reciprocal OAuth

As the author, I support the adoption. Do we have consensus now? On Tue, Apr 17, 2018 at 1:18 PM, William Denniss wrote: > +1, I support the adoption of this document. > > I've encountered this problem in the wild for account linking scenarios, > and I think it would be

Re: [OAUTH-WG] Call for agenda items

organize a conference call on > that topic if you and the group think that no such meeting is necessary. > > > > *From:* Dick Hardt [mailto:dick.ha...@gmail.com] > *Sent:* 18 April 2018 16:29 > > *To:* Hannes Tschofenig > *Cc:* n-sakimura; oauth > *Subject:* Re: [OAUTH-WG]

Re: [OAUTH-WG] Call for agenda items

as part of the OAuth working group is that > you involve other interested parties to the discussion, and that you do not > have to repeat your private conversations later again on the mailing list.. > > That’s pretty convincing to me ;-) > > > > Ciao > > Hannes > >

Re: [OAUTH-WG] Call for agenda items

ng a > f2f interim meeting for OAuth is possible we have not discussed this so > far. > > > > Ciao > Hannes > > > > *From:* OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *n-sakimura > *Sent:* 18 April 2018 07:34 > *To:* Dick Hardt; n-sakimura > *Cc:* o

Re: [OAUTH-WG] Call for agenda items

mbined draft. > > > Nat Sakimura > > -- > > PLEASE READ: This e-mail is confidential and intended for the named > recipient only. If you are not an intended recipient, please notify the > sender and delete this e-mail. > > > > > ---

Re: [OAUTH-WG] Call for agenda items

I'd like to coordinate a side meeting with Nat, Brian, myself and other interested parties in Montreal to discuss Distributed OAuth. If we have two meetings, I'd like a timeslot in the second to summarize the side meeting and discuss next steps (if any). Separately, I'd like a time slot for an

Re: [OAUTH-WG] Distributed OAuth interim meeting summary

There seemed to be interest in this problem area from a number of people. While the other referenced drafts solve aspects of the problem, the Distributed OAuth ID is a full solution to a class problems, but may be overly prescriptive in aspects. Here is how I see the different aspects of the

Re: [OAUTH-WG] draft-hardt-oauth-mutual-01

and inline again ... :) On Tue, Jan 16, 2018 at 1:50 PM, Brian Campbell <bcampb...@pingidentity.com> wrote: > Inline also... > > On Tue, Jan 16, 2018 at 2:25 PM, Dick Hardt <dick.ha...@gmail.com> wrote: > >> Comments inline ... >> >> On Tue, Jan 16, 2

Re: [OAUTH-WG] draft-hardt-oauth-mutual-01

Comments inline ... On Tue, Jan 16, 2018 at 1:11 PM, Brian Campbell wrote: > > *On client_id:* > With the authorization_code code grant (sec https://tools.ietf.org/html/rf > c6749#section-4.1.3), the client_id is "REQUIRED, if the client is not > authenticating with

Re: [OAUTH-WG] draft-hardt-oauth-mutual-01

, 2018 at 11:25 AM, Dick Hardt <dick.ha...@gmail.com> wrote: > Brian > > *grant type* > Thanks for the grant type pointers. > > *client_id* > The reciprocal flow by its nature is part of a code_grant flow, and I > expect that party A and party B can be reversed. G

Re: [OAUTH-WG] draft-hardt-oauth-mutual-01

re-submit the document with a new filename that matches >> the updated title. >> >> Ciao >> Hannes >> >> >> On 01/16/2018 03:39 PM, Dick Hardt wrote: >> > I have made changes based on feedback on the call this morning. Updated >> > version

[OAUTH-WG] draft-hardt-oauth-mutual-01

I have made changes based on feedback on the call this morning. Updated version at: https://datatracker.ietf.org/doc/draft-hardt-oauth-mutual/ /Dick ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Webex details for upcoming OAuth interim meetings

What is the agenda for the meeting tomorrow? When can me expect minutes of the meeting today be distributed? On Fri, Jan 5, 2018 at 10:23 AM Hannes Tschofenig wrote: > Here is the webex info for the two upcoming OAuth interim meetings. > > > > Ciao > > Hannes &

Re: [OAUTH-WG] Question on REQUIRED metadata in https://tools.ietf.org/html/draft-ietf-oauth-discovery-07

old favorite, the Resource Owner Password > Credentials flow doesn’t use it, correct? Likewise, the Client Credentials > flow doesn’t. I’ll plan to make appropriate updates in -08. > > > > -- Mike > > > > *From

[OAUTH-WG] Question on REQUIRED metadata in https://tools.ietf.org/html/draft-ietf-oauth-discovery-07

I was reviewing https://tools.ietf.org/html/draft-ietf-oauth-discovery-07 and noticed that in https://tools.ietf.org/html/draft-ietf-oauth-discovery-07#section-2 that authorization_endpoint is REQUIRED. I am working on deployments that are two-legged OAuth where there is no

[OAUTH-WG] updated filenames for IDs

https://datatracker.ietf.org/doc/draft-hardt-oauth-mutual/ https://datatracker.ietf.org/doc/draft-hardt-oauth-distributed/ -- Subscribe to the HARDTWARE mail list to learn about projects I am working on! ___ OAuth mailing list

Re: [OAUTH-WG] oauth - New Meeting Session Request for IETF 100

And secevent? On Wed, Sep 27, 2017 at 10:39 AM, Rifaat Shekh-Yusef wrote: > Sure, I will add that to the list. > > Regards, > Rifaat > > > On Wed, Sep 27, 2017 at 1:35 PM, Brian Campbell < > bcampb...@pingidentity.com> wrote: > >> Can we possibly also try and avoid

Re: [OAUTH-WG] [jose] preventing confusion of one kind of JWT for another in JWT BCP

Brian: I did not think that 'crit' processing is required in JWT https://tools.ietf.org/html/rfc7519 We have two goals: Preventing new JWT profiles from being confused with older JWTs, which 'typ' solves (as does your proposal of 'crit' and 'p', but requires more bytes) Preventing existing JWT

Re: [OAUTH-WG] [jose] preventing confusion of one kind of JWT for another in JWT BCP

Only if the audience is different. On Thu, Jul 27, 2017 at 10:00 PM, Nathaniel McCallum wrote: > Even after reading the whole section, I still don't understand the > problem. Yes, a class of attack could exist where an attacker > substitutes a valid JWT from one security

Re: [OAUTH-WG] JSON Web Token Best Current Practices draft describing Explicit Typing

Thanks for the feedback Justin. Do you have any specific wording? On Tue, Jul 18, 2017 at 6:34 PM Justin Richer wrote: > Mike et al, > > Overall, this document has some really great advice for people who have > chosen to use JWT in various situations. It’s a needed draft and

[OAUTH-WG] bidirectional authorization interest?

In Alexa, we are coming across scenarios where both parties are both a resource and an authorization server, and each of them requires an access token for the other. Is anyone else interested in such scenarios and would like to get together informally in Prague this week? /Dick

Re: [OAUTH-WG] oauth with command line clients

+1 to the device flow if you can't pop open a system browser. If you can pop open a system browser, then a more standard flow is a better CX. On Mon, Jun 12, 2017 at 11:34 AM, Phil Hunt wrote: > +1 > > The point of OAuth is to break away from using UID/Password (basic

Re: [OAUTH-WG] JOSE/JWT Security Update Presentation

Mike, Yaron Cheffer and myself have volunteered to write a JWT BCP. It is a topic on the agenda in the OAuth meeting currently underway. On Fri, Mar 31, 2017 at 9:58 AM, Dave Tonge wrote: > Thanks Mike > > I agree with all the next steps, we need some articles to

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

I reviewed the document and have no comments. +1 to adoption On Thu, Jul 21, 2016 at 1:05 AM, Hannes Tschofenig < hannes.tschofe...@gmx.net> wrote: > Hi all, > > William has submitted an update, as promised during the OAuth WG session > on Monday. Hence, we will start a Last Call for comments

[OAUTH-WG] URGENT: WPAD attack exposes URL contents even over HTTPS

http://arstechnica.com/security/2016/07/new-attack-that-cripples-https-crypto-works-on-macs-windows-and-linux/ Access tokens included as a URL query parameter when accessing a resource are susceptible to this attack. Authorization codes are also visible. From what I know, we have not depended on

Re: [OAUTH-WG] TAuth

to email this guy and learn more about what he's doing. > > --Justin > > *Sent from my phone* > > Original message > From: Brock Allen <brockal...@gmail.com> > Date: 5/10/16 6:44 PM (GMT-06:00) > To: Dick Hardt <dick.ha...@gmail.com>, Oauth

Re: [OAUTH-WG] Legal Notice on RFC 6749 - The OAuth 2.0 Authorization Framework

I'm not the right person to respond to you. On Sat, Mar 21, 2015 at 12:18 AM, le...@softalley.com wrote: Dear. Mr. Hardt Your committee for this RFC, and as a result, this RFC is infringing at least one of our patents, namely, US8972590. I would like to further discuss this matter and see

Re: [OAUTH-WG] Returning tokens directly to a human user

If you are interested in how others have done a similar flow, you could look at how smart TVs supporting Netflix and Amazon are authorized. On Fri, Mar 6, 2015 at 9:22 AM, Sergey Beryozkin sberyoz...@gmail.com wrote: Hi All, We might have a requirement to support a case where AS returns an

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

This change is appropriate and reflects the intent of the statement. On Tue, Feb 4, 2014 at 8:13 AM, RFC Errata System rfc-edi...@rfc-editor.org wrote: The following errata report has been submitted for RFC6749, The OAuth 2.0 Authorization Framework. --

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

My bad, sorry. On Tue, Feb 4, 2014 at 8:58 AM, Phil Hunt phil.h...@oracle.com wrote: +1 Phil On Feb 4, 2014, at 8:33, John Bradley ve7...@ve7jtb.com wrote: The text in 10.16 is correct. This is a security consideration that has caused serious problems for Facebook and other

Re: [OAUTH-WG] Unclear parts in OAuth 2.0 specification

On Fri, Aug 30, 2013 at 3:41 PM, Martin Ždila m.zd...@mwaysolutions.comwrote: Hello There are some unclear parts in OAuth 2.0 specification. *1.* In 4.3. (B) there is following statement: When making the request, the client authenticates with the authorization server. In 4.3.2

Re: [OAUTH-WG] JWT: add iss and aud to Reserved Header Parameter Names in JWE

in an unencrypted manner are replicated as Header Parameter values in the JWT.” ** ** -- Mike ** ** *From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf Of *Dick Hardt *Sent:* Wednesday, May 29, 2013 8:48 AM

Re: [OAUTH-WG] JWT: add iss and aud to Reserved Header Parameter Names in JWE

outside the encrypted payload ** ** *From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf Of *Dick Hardt *Sent:* Tuesday, May 28, 2013 9:34 AM *To:* O Auth WG *Subject:* Re: [OAUTH-WG] JWT: add iss and aud to Reserved Header Parameter Names in JWE ** ** Following

[OAUTH-WG] JWT: add iss and aud to Reserved Header Parameter Names in JWE

iss and aud would be optional parameters in a JWE. These parameters are in the payload, but since it is encrypted, the payload must be decrypted before they can be read. Some times knowing these parameters is required to be able to decrypt the payload … These would be additions to 9.3.1 in the

Re: [OAUTH-WG] JWT: add iss and aud to Reserved Header Parameter Names in JWE

-Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Dick Hardt Sent: Wednesday, May 01, 2013 2:12 PM To: O Auth WG Subject: [OAUTH-WG] JWT: add iss and aud to Reserved Header Parameter Names in JWE iss and aud would be optional parameters in a JWE

Re: [OAUTH-WG] OAuth2 attack surface....

I once again kick myself for not noticing the implicit flow was inserted into the spec … hopefully the warning labels keep others from supporting the implicit flow … but additional messaging about not supporting implicit flow would be useful. I can see why Facebook wanted it for the content

[OAUTH-WG] prn - sub :: draft-ietf-oauth-json-web-token-06.txt

Did I miss the discussion on this code breaking change? I'm ok with the change, but would have expected more discussion / notice about a change such as this. Before I run around and make edits to running code, I'd like to know if we are staying with this label. -- Dick

Re: [OAUTH-WG] December 27, 2012 OAuth Release

Looks like I was not the only one that was reading p0rn when I saw prn … ;-) On Dec 28, 2012, at 5:07 PM, Mike Jones michael.jo...@microsoft.com wrote: New versions of the OAuth JWT, JWT Bearer Profile, and Assertions specs have been released incorporating feedback since IETF 85 in Atlanta.

Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05

On Dec 23, 2012, at 9:41 AM, =JeffH jeff.hod...@kingsmountain.com wrote: Thanks for the replies, Jeff. They make sense. Particularly, thanks for the JSON Text Object suggestion. welcome, glad they made some sense. similarly, if one employs JSON arrays, I'd define a JSON text array.

Re: [OAUTH-WG] access tokens refresh tokens of different scopes

cases are a bit atypical for the wg, but It still seems to me to be in line with the OAuth spirit to keep the access token as restricted as possible (both in terms of lifetime and in terms of scope). adam From: Dick Hardt [mailto:dick.ha...@gmail.com] Sent: Wednesday, October 31, 2012

Re: [OAUTH-WG] access tokens refresh tokens of different scopes

On Oct 31, 2012, at 1:29 PM, Lewis Adam-CAL022 adam.le...@motorolasolutions.com wrote: Hi Dick, Totally agree about keeping things simple :) I’ll be the first to admit that many of my use cases are edge cases, but I was sort of hoping that “this one” might find some common mindshare

Re: [OAUTH-WG] RFC 6749 on The OAuth 2.0 Authorization Framework

Thanks everyone for all their work! We can now focus on the next layers in the identity stack. -- Dick On Oct 12, 2012, at 3:42 PM, rfc-edi...@rfc-editor.org wrote: A new Request for Comments is now available in online RFC libraries. RFC 6749 Title: The OAuth 2.0

Re: [OAUTH-WG] Implementation Support and Community

+1 to StackOverflow -- that has become the goto source for programming FAQs On Aug 23, 2012, at 7:38 AM, Justin Richer jric...@mitre.org wrote: With the core specs basically out the door and seeing wider adoption and publicity, the OAuth community is going to start to get more questions

Re: [OAUTH-WG] OAuth 1.0a

FYI: Google's SASL for IMAP is with OAuth 1.0A -- took me a while to get it working. On Aug 14, 2012, at 12:53 PM, William Mills wrote: I want to get the SASL work done. HoK is interesting, but I've become convinced that it's not actually anything that needs it's own spec, you can do HoK

Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01

12:18 PM, Dick Hardt wrote: As an implementor, I would pick a signed JWT over OAuth 1.0A. Just saying. Given that, there is also a clear need for signing an HTTP(S) request as some sites are choosing OAuth 1.0A over OAuth 2.0 because they don't want to use bearer tokens. I never followed

Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01

On Aug 9, 2012, at 9:52 AM, William Mills wrote: I find the idea of starting from scratch frustrating. MAC solves a set of specific problems and has a well defined use case. It's symmetric key based which doesn't work for some folks, and the question is do we try to develop something

Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01

there for OAuth 1.0a. MAC fits in to the OAuth 2 auth model and will provide for a single codepath for sites that want to use both Bearer and MAC. From: Dick Hardt dick.ha...@gmail.com To: William Mills wmills_92...@yahoo.com Cc: oauth@ietf.org oauth@ietf.org Sent: Thursday, August 9, 2012 10:27

Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01

9, 2012, at 1:47 PM, William Mills wrote: Mostly it's around making sure you get the signature base string constructed right in my experience. From: Dick Hardt dick.ha...@gmail.com To: William Mills wmills_92...@yahoo.com Cc: Dick Hardt dick.ha...@gmail.com; oauth@ietf.org oauth@ietf.org

[OAUTH-WG] Fwd: [IANA #596671] Protocol Action: 'The OAuth 2.0 Authorization Framework' to Proposed Standard (draft-ietf-oauth-v2-31.txt)

Would appreciate a few others checking to make sure the IANA entries are valid. -- Dick Begin forwarded message: From: Amanda Baber via RT drafts-appro...@iana.org Subject: [IANA #596671] Protocol Action: 'The OAuth 2.0 Authorization Framework' to Proposed Standard

Re: [OAUTH-WG] [IANA #596671] Protocol Action: 'The OAuth 2.0 Authorization Framework' to Proposed Standard (draft-ietf-oauth-v2-31.txt)

Hello Amanda (or whoever :) It would be nice if the OAuth Parameters were listed alphabetical. Also, the reference for the OAuth Access Token Types registry should be http://tools.ietf.org/html/draft-ietf-oauth-v2-31 - nothttp://tools.ietf.org/html/draft-ietf-oauth-urn-sub-ns-06. -- Dick On

[OAUTH-WG] Fwd: Approved: draft-ietf-oauth-v2

FYI Begin forwarded message: From: Stephen Farrell stephen.farr...@cs.tcd.ie Subject: Approved: draft-ietf-oauth-v2 Date: August 1, 2012 3:53:56 PM PDT Resent-To: dick.ha...@gmail.com, d...@fb.com Resent-To: de...@ihtfp.com, hannes.tschofe...@gmx.net, To:

Re: [OAUTH-WG] draft-ietf-oauth-v2

Thanks for the feedback Michael. 4.1.2 is where the authorization code is first talked about, and it makes sense to discuss how it is generated and used at that point. I can see how it might also be useful to put it in 4.1.3. Note that this is this is RECOMMENDED as opposed to MUST so it does

Re: [OAUTH-WG] Preliminary OAuth Core draft -29

and doing a code flow doesn't buy you any greater security, either. One can think of the client credential flow as the client already having the code and that the authorization happened out of band. No need to change any copy. On 07/09/2012 01:31 PM, Dick Hardt wrote: Hi Mike Reading over

Re: [OAUTH-WG] Report an authentication issue

On Jun 29, 2012, at 11:06 AM, John Bradley wrote: It is nice to know that I may occasionally be correct:) You must be delighted when it happens! ;) While you may assume that it is reasonable for a client with a code to make a request to the token endpoint including it's client_id and the

Re: [OAUTH-WG] Report an authentication issue

...@oracle.com On 2012-06-29, at 11:14 AM, Dick Hardt wrote: On Jun 29, 2012, at 11:06 AM, John Bradley wrote: It is nice to know that I may occasionally be correct:) You must be delighted when it happens! ;) While you may assume that it is reasonable for a client with a code to make

Re: [OAUTH-WG] New draft process / editor role

specification was published. * I had nothing to do with this draft. I did not edit or authored it. I didn't know it was being published. * The draft was authored by Mike Jones and published by Dick Hardt. * Neither one is an editor or an active author of the document. Here are the facts

Re: [OAUTH-WG] New draft process / editor role

On Jun 9, 2012, at 1:20 PM, Melinda Shore wrote: On 6/9/12 12:56 AM, Dick Hardt wrote: Mike emailed me the draft and asked if I would publish it. I reviewed the draft and I thought it captured consensus. Chairs call consensus. Agreed. I thought it captured the consensus that Hannes

Re: [OAUTH-WG] OAuth Core -27 Published

. I’ll be publishing an updated Bearer draft shortly that references the changes in -27 in ways that should resolve the outstanding DISCUSS issues against Bearer. Thanks to Dick Hart for publishing the draft. s/Dick Hart/Dick Hardt

Re: [OAUTH-WG] IPR on OAuth bearer

3) I have read the IPR and I believe I could deploy this specification. NOTE: I am not a legal expert, but I do have extensive experience with identity related patents and after reviewing the claims, I do not believe that the OAuth 2.0 or OAuth bearer specifications infringe on patent 7272639.

Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD)

A couple months ago I was checking out what was up. The AOL and Yahoo endpoints no longer worked. The Google one still did. On Apr 17, 2012, at 3:54 PM, Blaine Cook wrote: That's a tricky question - maybe one google can help answer? There are a bunch of projects using webfinger, including

Re: [OAUTH-WG] IIW and OAuth

I'd also prefer something during IIW schedule (tues - thu) -- Dick On 2012-04-16, at 9:42 AM, Justin Richer jric...@mitre.org wrote: Thursday would conflict with IIW sessions proper, and we'd prefer a Friday morning get together. -- Justin On 04/16/2012 12:27 PM, John Bradley wrote:

Re: [OAUTH-WG] A Scope Attack against OAuth 2.0

Some of the more interesting capabilities that an app can ask for are revokable by the user later on. Facebook has an API call /me/permissions That lets an app determine what permissions the user has granted the app. If need be the app can then ask (or re-ask) for additional scopes.

Re: [OAUTH-WG] SHOULD vs MUST for indicating scope on response when different from client request

+! On Jan 20, 2012, at 4:20 PM, Torsten Lodderstedt wrote: MUST sounds reasonable Eran Hammer e...@hueniverse.com schrieb: The current text: If the issued access token scope is different from the one requested by the client, the authorization server SHOULD include the

Re: [OAUTH-WG] Rechartering

fulfill the same scope just that each token is a subset of the requested scope. -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran Hammer-Lahav Sent: Monday, October 31, 2011 2:17 PM To: Dick Hardt Cc: OAuth WG; Dan Taflin Subject

Re: [OAUTH-WG] Rechartering

What if the access tokens come from different authoritative servers? On Oct 26, 2011, at 9:15 AM, Eran Hammer-Lahav wrote: Why not just ask for one access token with all the scopes you need, then refresh it by asking for the different subsets you want. EHL -Original Message-

Re: [OAUTH-WG] Possible alternative resolution to issue 26

slight preference for 3 and E -- Dick On 2011-10-03, at 6:56 PM, Mike Jones michael.jo...@microsoft.com wrote: As editor, based upon James’ input, I’d like to expand the set of choices for the working group to consider by adding the possibility of using JSON string encodings for scope and

Re: [OAUTH-WG] Bearer token credentials syntax

+1.1 On 2011-09-23, at 7:00 AM, Mike Jones wrote: James Manger and others pointed out that the current credentials syntax does not comply with RFC 2617, nor does it match the updated credentials syntax contained in HTTPbis, part 7: Authentication. The current syntax in the bearer token

Re: [OAUTH-WG] Refresh Tokens

My recollection of refresh tokens was for security and revocation. security: By having a short lived access token, a compromised access token would limit the time an attacker would have access revocation: if the access token is self contained, authorization can be revoked by not issuing new

Re: [OAUTH-WG] Refresh Tokens

If it was, no one told me. On 2011-08-11, at 12:41 PM, Anthony Nadalin wrote: Anonymity was certainly part of the design for WRAP From: Eran Hammer-Lahav [mailto:e...@hueniverse.com] Sent: Thursday, August 11, 2011 12:35 PM To: Anthony Nadalin; Dick Hardt Cc: OAuth WG (oauth@ietf.org

Re: [OAUTH-WG] Revised Charter

+1 to Eran and David's comments. Let's not get distracted when we are close to finalizing. I suggest revising the charter once we are done with 2.0 unless there is a process reason for revising the charter to complete 2.0. -- Dick On 2011-04-28, at 12:22 PM, David Recordon wrote: I agree

Re: [OAUTH-WG] Revised Section 3

On 2011-04-22, at 5:18 PM, Eran Hammer-Lahav wrote: Are you kidding me? “Not the best spelled out feature”? It is not spelled at all. Not using a single character! Maybe Dick was using magic ink for this section. No magic ink was used. :) Tony: I looked over your last emails and while I

Re: [OAUTH-WG] Revised Section 3

On 2011-04-19, at 10:51 AM, David Recordon wrote: I think requests like this and the following discussions have scared away many of the original voices behind OAuth 2.0. As Eran said, the goal was never to create a new framework but standardize interoperable best practices that the industry

Re: [OAUTH-WG] Revised Section 3

On 2011-04-19, at 11:41 AM, Eran Hammer-Lahav wrote: -Original Message- From: Dick Hardt [mailto:dick.ha...@gmail.com] Sent: Tuesday, April 19, 2011 11:37 AM The feature described was in OAuth-WRAP which was a basis for OAuth 2.0. Can you please point me to where

Re: [OAUTH-WG] Revised Section 3

is nevertheless the same - the section is out of the document pending working group consensus for inclusion. EHL [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-15#section-4.5 [2] http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-03 -Original Message- From: Dick Hardt

Re: [OAUTH-WG] Revised Section 3

is to add something like 4.4.3 to 4.5? That sounds like a good idea. Would that resolve the potential confusion here? EHL From: Dick Hardt dick.ha...@gmail.com Date: Tue, 19 Apr 2011 13:25:15 -0700 To: Eran Hammer-lahav e...@hueniverse.com Cc: record...@gmail.com record...@gmail.com

Re: [OAUTH-WG] to TLS or not on redirect on consumer websites :: security considerations

On 2011-04-02, at 11:13 AM, Francisco Corella wrote: Another example I mentioned earlier is when the client does not expose the protected resources back to the bearer of the code. For example, a Twitter application sending you emails when someone stops following you. Since all it does

Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt

On 2011-03-31, at 7:32 AM, Skylar Woodward wrote: A requirement for TLS on the callback would make OAuth prohibitive for many of our developers. The developers are usually volunteers and they are already donating their own resources to help a non-profit (from which US law mandates the

Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt

On 2011-03-30, at 8:19 AM, Dick Hardt wrote: Thanks for pointing out my misunderstanding. I was thinking client in the sense of the side of TLS initiating a request. I agree that requiring TLS on the callback is an unexpected change. I recall reviewing the security implications

Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt

On 2011-03-29, at 4:40 PM, Eran Hammer-Lahav wrote: To clarify, I am not opposed to mandating TLS on the callback, just that if we do, we can’t ship the protocol the way it is without coming up with some other alternative that does not require TLS deployment on the client side. OAuth 1.0

Re: [OAUTH-WG] Authors, Contributors, Acknowledgement

I'm fine with any of the options Eran proposed. The document has become much more Eran's than anyone else's which leads me to lean towards just listing Eran as the editor. -- Dick On 2011-03-27, at 1:43 AM, Peter Saint-Andre wrote: hat type='AD'/ On 3/27/11 12:36 AM, Eran Hammer-Lahav

Re: [OAUTH-WG] slightly alternative preamble (was: Re: Draft -12 feedback deadline)

. But in the absence of any specific solution or recommendation from the WG regarding native apps, I am simply asking that the somewhat misleading text be removed from the framework spec. On Sun, Mar 6, 2011 at 3:12 PM, Dick Hardt dick.ha...@gmail.com wrote: -1 Many sites are using OAuth

Re: [OAUTH-WG] Feedback on JSON Web Token (JWT) draft -01

with no standard library. -jeff On Fri, Jan 7, 2011 at 10:42 AM, Dick Hardt dick.ha...@gmail.com wrote: Hi Jeff Thanks for the feedback. A healthy debate is how we optimize a spec! Will a slightly shorter token be significant for you? Is the rest of the message so short that a smaller token

Re: [OAUTH-WG] Feedback on JSON Web Token (JWT) draft -01

Hi Jeff Thanks for the feedback. A healthy debate is how we optimize a spec! Will a slightly shorter token be significant for you? Is the rest of the message so short that a smaller token will have a significant impact? The hope is that if we standardize JWT, that libraries will be developed

<    1   2   3   4   5   >