I disagree with Mike on several points, and we have had this argument before :)
MAC is not interchangable with 1.0a though they are close. We might define
1.0a token usage for 2.0
Holding MAC while we figure out HOK is not my favorite, and if you look at the
current MAC draft it has HOK
The new signature base string stuff still needs work, I wanted to tackle more
major restructuring first. I want to pull all of those things out of the query
string.
From: Sergey Beryozkin sberyoz...@gmail.com
To: William Mills wmills_92...@yahoo.com
Cc
I'm actually advocating that we change MAC to be a JWT extension.
From: Hannes Tschofenig hannes.tschofe...@gmx.net
To: William Mills wmills_92...@yahoo.com
Cc: Hannes Tschofenig hannes.tschofe...@gmx.net; oauth@ietf.org
oauth@ietf.org
Sent: Thursday
is duplicated from anywhere else.
From: Justin Richer jric...@mitre.org
To: William Mills wmills_92...@yahoo.com
Cc: Hannes Tschofenig hannes.tschofe...@gmx.net; oauth@ietf.org
oauth@ietf.org
Sent: Thursday, February 28, 2013 9:08 AM
Subject: Re: [OAUTH-WG] I-D
.
From: Sergey Beryozkin sberyoz...@gmail.com
To: oauth@ietf.org
Sent: Thursday, February 28, 2013 9:04 AM
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt
Hi
On 28/02/13 13:14, William Mills wrote:
I'm actually advocating that we change
I certainly hope so.
From: Sergey Beryozkin sberyoz...@gmail.com
To: William Mills wmills_92...@yahoo.com
Cc: oauth@ietf.org oauth@ietf.org
Sent: Thursday, February 28, 2013 10:02 AM
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt
William Mills
Hannes Tschofenig
Filename : draft-ietf-oauth-v2-http-mac-03.txt
Pages : 26
Date : 2013-02-25
Abstract:
This specification describes how to use MAC Tokens in HTTP requests
to access OAuth 2.0 protected resources
And also...
How would the server mandate a set of header fields requiring signature? How
can the server mandate a signature method or do we just stay with the two
options and allow either? It might want to enforce SA-256?
-bill
From: William Mills
I think this is worth a read, I don't have time to dive into this :(___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
DOH!!!
http://homakov.blogspot.co.uk/2013/02/hacking-facebook-with-oauth2-and-chrome.html
From: Phil Hunt phil.h...@oracle.com
To: William Mills wmills_92...@yahoo.com
Sent: Monday, February 25, 2013 2:28 PM
Subject: Re: [OAUTH-WG] OAuth2 attack surface
I'll repeat the use case for Flickr, which requires OAuth 1.0a type capabilites
that OAuth 2 does not provide. Simply stating move to HTTPS is not a viable
response here.
From: Torsten Lodderstedt tors...@lodderstedt.net
To: William Mills wmills_92
Exactly. And in the Flickr case replay of the same event is not a problem.
Thanks for keeping me honest, work just cranked the dial up to 11.5 so I'm a
bit distracted.
From: Phil Hunt phil.h...@oracle.com
To: William Mills wmills_92...@yahoo.com
Cc: Torsten
On 15/02/13 16:09, William Mills wrote:
I'll repeat the use case for Flickr, which requires OAuth 1.0a type
capabilites that OAuth 2 does not provide. Simply stating move to
HTTPS is not a viable response here.
*From
Because we're goign to want a single implementation, not N.
From: Tim Bray twb...@google.com
To: William Mills wmills_92...@yahoo.com
Cc: Torsten Lodderstedt tors...@lodderstedt.net; IETF oauth WG
oauth@ietf.org
Sent: Friday, February 15, 2013 8:49 AM
Subject
I disagree with That was the impediment to OAuth 1.0 adoption that OAuth 2.0
solved in the first place., unless solving means does not address the need
for it at all.
OAuth 2 does several good things, but it still lacks a defined token type that
is safe to user over plain text HTTP. 1.0a
You have a trust relationship with the user and perhaps with the client.
From: Prateek Mishra prateek.mis...@oracle.com
To: oauth@ietf.org
Sent: Wednesday, February 13, 2013 8:13 AM
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call -
Is key distribution how AS and PR share keys for token encryption/decryption
or specifically about the keys for the HOK tokens?
For the MAC token spec, I don't actually care whether we use JSON or now, but
I'm in full agreement that we do NOT duplicate any HTTP info into the JSON.
Just
then.
From: Hannes Tschofenig hannes.tschofe...@gmx.net
To: William Mills wmills_92...@yahoo.com
Cc: Hannes Tschofenig hannes.tschofe...@gmx.net; IETF oauth WG
oauth@ietf.org
Sent: Tuesday, February 12, 2013 1:44 AM
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team
: Hannes Tschofenig hannes.tschofe...@gmx.net; William Mills
wmills_92...@yahoo.com; IETF oauth WG oauth@ietf.org
Sent: Tuesday, February 12, 2013 3:06 AM
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call -
11th February 2013
The transport of the session key from
+1
From: Prabath Siriwardena prab...@wso2.com
To: Todd W Lainhart lainh...@us.ibm.com
Cc: oauth@ietf.org WG oauth@ietf.org; oauth-boun...@ietf.org
Sent: Wednesday, February 6, 2013 7:04 AM
Subject: Re: [OAUTH-WG] A question on token revocation.
On Wed,
?
From: Prabath Siriwardena prab...@wso2.com
To: William Mills wmills_92...@yahoo.com
Cc: L. Preston Sego III lpse...@gmail.com; oauth@ietf.org oauth@ietf.org
Sent: Wednesday, February 6, 2013 8:23 AM
Subject: Re: [OAUTH-WG] I'm concerned about how the sniffability of oauth2
requests
There are some specific design mis-matches for OAuth as an authentication
protocol, it's not what it's designed for and there are some problems you will
run into. Some have used it as such, but it's not a good general solution.
-bill
From: Paul Madsen
, but why rebuild OpenID when OpenID exists?
-bill
From: Lewis Adam-CAL022 adam.le...@motorolasolutions.com
To: Tim Bray twb...@google.com; William Mills wmills_92...@yahoo.com
Cc: oauth@ietf.org WG oauth@ietf.org
Sent: Tuesday, February 5, 2013 2:27 PM
Subject
There are two efforts at signed token types: MAC which is still a possibility
if we wake up and do it, and the Holder Of Key type tokens.
There are a lot of folks that agree with you.
From: L. Preston Sego III lpse...@gmail.com
To: oauth@ietf.org
Sent:
1) I think that we need to focus on specific solutions, as I said on the call,
and solve the OAuth 1.0a/MAC use case. There's significant installed base of
OAuth 1.0a and we need a path for those installations into OAuth 2.0. I may
well pursue MAC in the interim to do this, but a full HOK
about it.
From: Prateek Mishra prateek.mis...@oracle.com
To: oauth@ietf.org; William Mills wmills_92...@yahoo.com
Sent: Monday, February 4, 2013 1:28 PM
Subject: Re: [OAUTH-WG] conf call follow up from today
Bill -
How does OAuth 1.0a deal with the problem
We can do that too, and I rather like it. I thought there was a big don't
cross the beams warning somewhere though.
-bill
From: Richer, Justin P. jric...@mitre.org
To: William Mills wmills_92...@yahoo.com
Cc: O Auth WG oauth@ietf.org
Sent: Monday, February
Why do we need invalid_token as an error code at all? To me it only introduces
a way to get information about tokens. Invalid parameter I can see as a use
case, but if the token is invalid just return 200/OK because there is nothing
to do.
-bill
From:
Here is probably your best bet if it's a design question. If it's a specific
implementation then send it to the company in question first if you think they
have a vulnerability.
From: L. Preston Sego III lpse...@gmail.com
To: oauth@ietf.org
Sent: Thursday,
This is true. It's possible for the AS to vary it's behavior on scope name,
but it's presumed the AS and RS have an agreement of what token type is in
play. Likely a good extension to the spec.
From: Prabath Siriwardena prab...@wso2.com
To: oauth@ietf.org WG
Not a problem for the client to request a type, but it may not get it.
From: zhou.suj...@zte.com.cn zhou.suj...@zte.com.cn
To: Prabath Siriwardena prab...@wso2.com
Cc: oauth@ietf.org WG oauth@ietf.org; William Mills
wmills_92...@yahoo.com
Sent: Sunday
It's the core problem I see MAC solving. I'd be happy enough to define a JWT
variant that does this if that's easier than MAC. What do you think?
From: Mike Jones michael.jo...@microsoft.com
To: William Mills wmills_92...@yahoo.com; oauth@ietf.org oauth
FYI
http://prosecco.gforge.inria.fr/CVE/Facebook_JS_2012.html
As a part of our study of various security critical Javascript SDKs we
did an analysis of the Facebook Connect JS SDK. Since they use HTML5
based PostMessage API we were specifically interested in the way the
origins were
...@ve7jtb.com
To: William Mills wmills_92...@yahoo.com
Cc: Mike Jones michael.jo...@microsoft.com; oauth@ietf.org oauth@ietf.org
Sent: Friday, January 4, 2013 3:44 PM
Subject: Re: [OAUTH-WG] December 27, 2012 OAuth Release
If everything you want to sign can go in the JWT there is nothing to stop
That would work. Register a link relation property for supported signing
methods.
From: John Bradley ve7...@ve7jtb.com
To: William Mills wmills_92...@yahoo.com
Cc: Mike Jones michael.jo...@microsoft.com; oauth@ietf.org oauth@ietf.org
Sent: Friday, January 4
Don't use OAuth, use OpenID. OAuth isn't designed for authentication and
OpenID is.
From: Adrian Servenschi adr...@c4media.com
To: oauth@ietf.org
Sent: Wednesday, January 2, 2013 1:25 PM
Subject: [OAUTH-WG] need advice on sign out after performing sign in via
Mike,
I've read through the JWT spec and I'm curious about something. How do I
specify a signature requirement as the server? I didn't see it but I probably
just missed it. I'm thinking that with very little work a JWT can do
everything that MAC does with greater flexibility, *BUT* the
zhou.suj...@zte.com.cn
To: William Mills wmills_92...@yahoo.com
Cc: oauth@ietf.org oauth,_oauth-boun...@ietf.org; SergeyBeryozkin
sberyoz...@yahoo.com
Sent: Thursday, December 20, 2012 11:46 PM
Subject: Re: Re: [OAUTH-WG] Few questions about HOTK
oauth-boun...@ietf.org 写于 2012-12-21 13:30:08:
MAC
No, MAC as I'm using it is a MAC token
per http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-02
From: Sergey Beryozkin sberyoz...@gmail.com
To: William Mills wmills_92...@yahoo.com
Cc: oauth@ietf.org oauth@ietf.org
Sent: Friday, December 21, 2012 3:15
information.
From: Sergey Beryozkin sberyoz...@gmail.com
To: William Mills wmills_92...@yahoo.com
Cc: oauth@ietf.org oauth@ietf.org
Sent: Friday, December 21, 2012 7:59 AM
Subject: Re: [OAUTH-WG] Few questions about HOTK
On 21/12/12 15:54, William Mills wrote:
No, MAC
MAC and HOTK describe different properties of a token, and could both be used
in the same token. MAC specifies a basic format for a signed token payload and
transaction. HOTK defines part of a token payload. HOTK payload can be
carried in a MAC token.
-bill
I don't see in that document a significant use case for a signed token, which
is use over clear text channels. Bearer tokens have similar security
properties to HTTP cookies (minus for the moment the XSRF problem). Signed
token types can be used over plain text channels without the concern
Yes!
The other thing that is better in the OAuth 2 model is the refresh capability,
which makes plain text channel token usage more palatable.
From: Richer, Justin P. jric...@mitre.org
To: William Mills wmills_92...@yahoo.com
Cc: Tschofenig, Hannes (NSN - FI
I object to tying MAC to HOK, I see them as independent and I frankly don't
understand why folks insist that MAC can not proceed without a broader HOK
spec.
-bill
From: Phil Hunt phil.h...@oracle.com
To: Sergey Beryozkin sberyoz...@gmail.com
Cc:
Yes, exactly right. The client gets a hint about the AT lifespan, but must
always handle the error response too. If the AT fails with a 401 then you try
a refresh. If the refresh fails and you get a 401 response then you
re-authenticate the user. Other 4XX error codes mean something
401 not 400
From: Justin Richer jric...@mitre.org
To: Sergey Beryozkin sberyoz...@gmail.com
Cc: oauth@ietf.org
Sent: Wednesday, November 21, 2012 6:11 AM
Subject: Re: [OAUTH-WG] How the client can decide it is time to use the refresh
token
There's no
The Authorization scheme name in the Authorization header tells you
From: Ib Lundgren ib.lundg...@gmail.com
To: oauth@ietf.org
Sent: Sunday, November 18, 2012 8:57 AM
Subject: [OAUTH-WG] Identifying token type during protected resource access
Hey everyone,
I think a resource server might validly revoke a token, but that a client will
not.
-bill
- Original Message -
From: Hannes Tschofenig hannes.tschofe...@gmx.net
To: William Mills wmills_92...@yahoo.com
Cc: Hannes Tschofenig hannes.tschofe...@gmx.net; Torsten Lodderstedt
tors
Revocation endpoint discovery can be handled through standard discovery
mechanisms. I don't think clients should request revocation (see earlier
message).
From: Hannes Tschofenig hannes.tschofe...@gmx.net
To: oauth@ietf.org WG oauth@ietf.org
Sent: Monday,
It could even, theoretically, be included in the Access Token!
It certainly could, this is the simplest form of holder of key in fact.
From: Derek Atkins de...@ihtfp.com
To: Hannes Tschofenig hannes.tschofe...@gmx.net
Cc: oauth@ietf.org oauth@ietf.org
Sent:
Are you trying to limit how widely the more powerful token gets used so peer
systems can't access each other? What problem does this solve?
That said I think you want to turn in an AT and get back N tokens with all
possible subordinate scopes if in fact this is worth doing. AT1 with scop a
You're doubling the number of back end calls to satisfy a request though, and
in the end you're only really getting a benefit when the back end system would
never see an ubertoken anyway.
From: Justin Richer jric...@mitre.org
To: William Mills wmills_92
It's a hint to the client of when the token will probably expire. There was a
lot of discussion on what the right way to go was and there were several
camps on the right strategy choice would be, but in the end a very simple
solution was chosen. Most folks agreed that having more than one way
.
I think you also mistaken that we can't support 1.0a and OAuth 2 tokens in the
same SASL mechanism. Why do you think this is true?
From: Hannes Tschofenig hannes.tschofe...@gmx.net
To: William Mills wmills_92...@yahoo.com
Cc: Hannes Tschofenig hannes.tschofe
From: Hannes Tschofenig hannes.tschofe...@gmx.net
To: William Mills wmills_92...@yahoo.com
Cc: Hannes Tschofenig hannes.tschofe...@gmx.net; Torsten Lodderstedt
tors...@lodderstedt.net; O Auth WG oauth@ietf.org
Sent: Tuesday, August 14, 2012 10:49 PM
Subject: Re: [OAUTH-WG] OAuth 1.0a
Hi Bill
to provide
comatibility.
-bill
From: Hannes Tschofenig hannes.tschofe...@nsn.com
To: William Mills wmills_92...@yahoo.com; Hannes Tschofenig
hannes.tschofe...@gmx.net
Cc: O Auth WG oauth@ietf.org
Sent: Tuesday, August 14, 2012 11:32 PM
Subject: Re: [OAUTH-WG
Thanks.
From: Mike Jones michael.jo...@microsoft.com
To: William Mills wmills_92...@yahoo.com; Dick Hardt dick.ha...@gmail.com;
oauth@ietf.org WG oauth@ietf.org
Sent: Tuesday, August 14, 2012 11:43 AM
Subject: RE: [OAUTH-WG] Fwd: [IANA #596670] Protocol Action
the SASL mechanism is build to properly handle signed auth
schemes and not just bearer (cookie) type.
-bill
From: Mike Jones michael.jo...@microsoft.com
To: William Mills wmills_92...@yahoo.com; O Auth WG oauth@ietf.org
Sent: Tuesday, August 14, 2012 12:28 PM
to vary a lot
from the elements that would currently be needed to support MAC or 1.0a and if
needed can just extend the SASL mechanism.
-bill
From: Torsten Lodderstedt tors...@lodderstedt.net
To: William Mills wmills_92...@yahoo.com
Cc: Mike Jones michael.jo
Yeah, I still need 1.0a to work which I was hoping to replace with MAC.
From: Mike Jones michael.jo...@microsoft.com
To: William Mills wmills_92...@yahoo.com; Torsten Lodderstedt
tors...@lodderstedt.net
Cc: O Auth WG oauth@ietf.org
Sent: Tuesday, August 14
1) Is it a problem that everything here seems to have specification required
for the Registration Procedures?
2) In HTTP Authentication schemes, is the case insensitivity implicit here?
(I think so)
-bill
From: Dick Hardt dick.ha...@gmail.com
To:
certificates we should do
that separately.
From: John Bradley ve7...@ve7jtb.com
To: William Mills wmills_92...@yahoo.com
Cc: David Waite da...@alkaline-solutions.com; oauth@ietf.org
oauth@ietf.org
Sent: Thursday, August 9, 2012 8:47 PM
Subject: Re: [OAUTH-WG
From: Hannes Tschofenig hannes.tschofe...@gmx.net
To: William Mills wmills_92...@yahoo.com
Cc: Hannes Tschofenig hannes.tschofe...@gmx.net; John Bradley
ve7...@ve7jtb.com; oauth@ietf.org oauth@ietf.org
Sent: Friday, August 10, 2012 12:01 AM
Subject: Re
It's not intended to address anything in TLS other than the fact that we have
real use cases where TLS isn't in play.
From: John Bradley ve7...@ve7jtb.com
To: William Mills wmills_92...@yahoo.com
Cc: David Waite da...@alkaline-solutions.com; oauth@ietf.org
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 that supports both PK and SK, or finish the SK use case
...@gmail.com
To: William Mills wmills_92...@yahoo.com
Cc: oauth@ietf.org oauth@ietf.org
Sent: Thursday, August 9, 2012 10:27 AM
Subject: 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
Bradley ve7...@ve7jtb.com
To: William Mills wmills_92...@yahoo.com
Cc: Dick Hardt dick.ha...@gmail.com; oauth@ietf.org oauth@ietf.org
Sent: Thursday, August 9, 2012 11:26 AM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
In Vancouver the question was asked about the future
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
Sent
Justin,
Count me in to help revive this and get it done.
-bill
From: Justin Richer jric...@mitre.org
To: oauth@ietf.org
Sent: Wednesday, August 8, 2012 8:08 AM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
Thanks Justas. The MAC
The server would need to issue a key pair and not just the private key. Are
you saying the private key is for the certificate, and that certificate is part
of the access_token?
From: Manger, James H james.h.man...@team.telstra.com
To: Hannes Tschofenig
Ah... sigh. I did reply yesterday, but never got connection information.
From: Tschofenig, Hannes (NSN - FI/Espoo) hannes.tschofe...@nsn.com
To: William Mills wmills_92...@yahoo.com; Hannes Tschofenig
hannes.tschofe...@gmx.net; OAuth WG oauth@ietf.org
Sent
I'll try to attend this.
From: Hannes Tschofenig hannes.tschofe...@gmx.net
To: OAuth WG oauth@ietf.org
Sent: Sunday, July 8, 2012 11:03 AM
Subject: [OAUTH-WG] 'Finishing up design team' Conference Call
I don't know why Google Hangout does not forward my
Aesthetically this makes my tummy hurt...
That said, I think it will work, and I'm willing to go with it.
From: Mike Jones michael.jo...@microsoft.com
To: George Fletcher gffle...@aol.com
Cc: oauth@ietf.org oauth@ietf.org
Sent: Friday, June 15, 2012 10:30
I agree generally with your assumption about clients, but rather than saying
clients are devices I think it makes much more sense to say clients are NOT
users, so client_id need not be internationalized. In practical terms there
is very little to argue for anythign beyond ASCII in a
From: Eran Hammer e...@hueniverse.com
To: Mike Jones michael.jo...@microsoft.com; William Mills
wmi...@yahoo-inc.com; Hannes Tschofenig hannes.tschofe...@gmx.net; Julian
Reschke julian.resc...@gmx.de
Cc: oauth@ietf.org oauth@ietf.org
Sent: Tuesday, June 12, 2012 11:39 AM
Subject
of type
uri_client_id MUST NOT use HTTP Basic client authentication.?
-bill
From: Eran Hammer e...@hueniverse.com
To: George Fletcher gffle...@aol.com
Cc: Mike Jones michael.jo...@microsoft.com; William Mills
wmi...@yahoo-inc.com; Hannes Tschofenig hannes.tschofe
+1
From: Anthony Nadalin tony...@microsoft.com
To: Eran Hammer e...@hueniverse.com; oauth@ietf.org WG (oauth@ietf.org)
oauth@ietf.org
Sent: Friday, June 8, 2012 7:18 PM
Subject: Re: [OAUTH-WG] New draft process / editor role
Why rant here, talk to the
I will not be attending in person, but will probably attend by conference call.
-bill
From: Hannes Tschofenig hannes.tschofe...@gmx.net
To: oauth@ietf.org WG oauth@ietf.org
Sent: Saturday, June 2, 2012 12:46 AM
Subject: [OAUTH-WG] Meeting slot for the
We've definitely needed full ABNF, this is good. I don't like the habit of
multiple definitions for the same character sets though. Things like %x21 /
%x23-5B / %x5D-7E should be named once and re-used.
From: Mike Jones michael.jo...@microsoft.com
To:
And yet, the security properties of query parameters make them not ideal for
credentials. From a security perspective it is hard to justify recommending it.
From: David Recordon record...@gmail.com
To: Mark Nottingham m...@mnot.net; Eran Hammer
wfm
From: Mike Jones michael.jo...@microsoft.com
To: oauth@ietf.org oauth@ietf.org
Cc: Mark Nottingham m...@mnot.net
Sent: Thursday, May 17, 2012 3:11 PM
Subject: [OAUTH-WG] FYI - Text resolving DISCUSS issue about Bearer URI Query
Parameter method
. But Bearer insists on 401 instead of redirects and that
confused me.
Sergey
On Tue, May 15, 2012 at 6:24 PM, William Mills wmi...@yahoo-inc.com wrote:
You can hard configure it into your client, that's safe. The problem comes
when the client can be sent to an arbitrary, possibly phishing, site to do
...@team.telstra.com
To: William Mills wmi...@yahoo-inc.com; oauth@ietf.org oauth@ietf.org
Sent: Wednesday, May 16, 2012 5:55 AM
Subject: RE: [OAUTH-WG] OAuth Bearer: Response to an unauthenticated request
Bill,
A WWW-Authenticate response header that identifies an authorization
server (AS) would
I think there is a need for a signed token style OAuth 2 scheme, and MAC fills
this niche, although holder-of-key (as yet un-drafted) would also do this
nicely. Is MAC going to get picked up and driven to completion?
Do others feel this token style (and security properties) are needed? Or
The problem is not with the auth servers, it's with clients that support
password grant. If they trust info sent to them by a resource server they will
give up the goods.
From: Manger, James H james.h.man...@team.telstra.com
To: William Mills wmi...@yahoo
Yes, what you're running across here is the discovery problem. How do you
discover the authentication endpoints for a service. Unfortunately it turns
out returning that as part of the 401 has big security concerns. It's still
being figured out.
From:
.
-bill
From: Sergey Shishkin sergei.shish...@gmail.com
To: William Mills wmi...@yahoo-inc.com
Cc: oauth@ietf.org oauth@ietf.org
Sent: Tuesday, May 15, 2012 9:09 AM
Subject: Re: [OAUTH-WG] OAuth Bearer: Response to an unauthenticated request
In my scenario I
Kitten is in the CC list because this applies to the discovery needs of the
OAUTH SASL draft.
From: SM s...@resistor.net
To: Justin Richer jric...@mitre.org
Cc: kit...@ietf.org; oauth@ietf.org
Sent: Friday, May 11, 2012 12:19 AM
Subject: Re: [OAUTH-WG]
Is it correct to say that the IPR in question touched the portion of Bearer
that deals with allowing the token in the URL, and that tokens in the Auth
header and tokens in POST body?
If so, then for me this issue is another reason not to use tokens in the URL,
which I would already recommend
So you are guaranteeing that there are no clients using WF today?
From: Mike Jones michael.jo...@microsoft.com
To: Paul E. Jones pau...@packetizer.com; 'Murray S. Kucherawy'
m...@cloudmark.com; oauth@ietf.org oauth@ietf.org; 'Apps Discuss'
Scope having actual meaning to the client (you usage of 'offline' is what I'm
looking at) is something you can define but is not something currently in the
protocol.
I think it's a simpler picture than you are painting:
1) You might get a hint with the expires_in value for when the token
I would characterize it as two distinct camps, folks that think WF can be
updated to do what SWD (growing contingent I think) does and folks that are
invested in SWD. I haven't seen any movement between those two camps,
specifically that the SWD folks think WF can in fact solve their problem
Various additional anti-abuse controls can be applied like CAPTCHA if you have
a full browser to leverage. Much harder to get that flexibility in a fixed
client UI.
From: Paul Madsen paul.mad...@gmail.com
To: adam.le...@motorolasolutions.com;
Yeah, we encountered this problem doing a binding between FB and other
accounts. We found that FB actually used a valid browser cookie rather than
serving back the needed auth page we wanted for the user. We had to work
around this by calling their un-CSRF protected sign-out link first.
I am planning to.
-bill
From: Hannes Tschofenig hannes.tschofe...@gmx.net
To: oauth@ietf.org WG oauth@ietf.org
Sent: Monday, April 16, 2012 4:55 AM
Subject: [OAUTH-WG] IIW and OAuth
Hi guys,
I was wondering how many of you will be at the upcoming IIW in
Yeah, SCIM as a way to federate and distribute info like this seems sane, with
extensions for the data items we need here. The hard part is still around the
security stuff which they have not dealt with yet, and that's going to be a
blocker until it's solved. Authority to update elemnts or
Or perhaps update/extend the existing spec to do what is needed? Is there
anything that is fundamentally in conflict?
-bill
From: Igor Faynberg igor.faynb...@alcatel-lucent.com
To: John Bradley ve7...@ve7jtb.com
Cc: oauth@ietf.org
Sent: Thursday, April
is far easier to deal with than XML, and I think that's probably
also really true, so there are some competing isues.
-bill
From: Eran Hammer e...@hueniverse.com
To: William Mills wmi...@yahoo-inc.com; Derek Atkins de...@ihtfp.com;
s...@ietf.org s...@ietf.org
On the SWD stuff there was general discussion about is this the right place?,
and there were issues raised. The question was also asked well, where is
the right place? which got crickets. It is exactly coming back to the list
for discussion to sort out the right place.
Can you specify the user being accesses as the resource in the URL?
P.S. Please start using the
http://twiki.corp.yahoo.com/view/Paranoidyahoos/SecurityRequest for new
requests like product and feature reviews.
From: David Fox da...@davidjfox.com
To:
1 - 100 of 243 matches
Mail list logo
