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 prope
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
To: William Mills
Cc: "oauth@ietf.org"
Sent: Frida
I certainly hope so.
From: Sergey Beryozkin
To: William Mills
Cc: "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
On 28/02/13 17:49, William Mills wrote:
er or post body.
From: Sergey Beryozkin
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 chan
is duplicated from anywhere else.
From: Justin Richer
To: William Mills
Cc: Hannes Tschofenig ; "oauth@ietf.org"
Sent: Thursday, February 28, 2013 9:08 AM
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt
What I don'
I'm actually advocating that we change MAC to be a JWT extension.
From: Hannes Tschofenig
To: William Mills
Cc: Hannes Tschofenig ; "oauth@ietf.org"
Sent: Thursday, February 28, 2013 2:28 AM
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oa
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
To
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol Working Group of
the IETF.
Title : OAuth 2.0 Message Authentication Code (MAC) Tokens
Author(s) : Justin Richer
DOH!!!
http://homakov.blogspot.co.uk/2013/02/hacking-facebook-with-oauth2-and-chrome.html
From: Phil Hunt
To: William Mills
Sent: Monday, February 25, 2013 2:28 PM
Subject: Re: [OAUTH-WG] OAuth2 attack surface
Whats the link?
Phil
Sent from my
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
Because we're goign to want a single implementation, not N.
From: Tim Bray
To: William Mills
Cc: Torsten Lodderstedt ; IETF oauth WG
Sent: Friday, February 15, 2013 8:49 AM
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call -
Thanks, Sergey
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.
>
> -
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
To: William Mills
Cc: Torsten Lodderstedt ; Mike Jones
; Justin R
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
To: William Mills
Cc: Mike Jones
over plain text with integrity
protection.
-bill
From: Torsten Lodderstedt
To: William Mills
Cc: Mike Jones ; Justin Richer
; Phil Hunt ; IETF oauth WG
Sent: Thursday, February 14, 2013 10:05 PM
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team
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 s
You have a trust relationship with the user and perhaps with the client.
From: Prateek Mishra
To: oauth@ietf.org
Sent: Wednesday, February 13, 2013 8:13 AM
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call -
11th February 2013
Hannes
could easily be used as part
of the signing key. So I feel like this will fatten up the token, potentially
a lot.
If we don't put it in the token this problem is WAY harder.
From: Hannes Tschofenig
To: Antonio Sanso
Cc: Hannes Tschofenig ; William Mil
contained then.
From: Hannes Tschofenig
To: William Mills
Cc: Hannes Tschofenig ; IETF oauth WG
Sent: Tuesday, February 12, 2013 1:44 AM
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call -
11th February 2013
Hi Bill,
On Feb 12, 2013, at 11
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 signat
owser?
From: Prabath Siriwardena
To: William Mills
Cc: L. Preston Sego III ; "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
On Mon, Feb 4, 2013 at 9:57 PM, William Mill
+1
From: Prabath Siriwardena
To: Todd W Lainhart
Cc: "oauth@ietf.org WG" ; oauth-boun...@ietf.org
Sent: Wednesday, February 6, 2013 7:04 AM
Subject: Re: [OAUTH-WG] A question on token revocation.
On Wed, Feb 6, 2013 at 7:51 PM, Todd W Lainhart wrote:
user info, sure, but why rebuild OpenID when OpenID exists?
-bill
From: Lewis Adam-CAL022
To: Tim Bray ; William Mills
Cc: "oauth@ietf.org WG"
Sent: Tuesday, February 5, 2013 2:27 PM
Subject: RE: [OAUTH-WG] Why OAuth it self is not an authenti
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
To: Jo
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."
To: William Mills
Cc: O Auth WG
Sent: Monday, February 4, 2013 1:37 PM
Subject:
about it.
From: Prateek Mishra
To: oauth@ietf.org; William Mills
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 of HTTP URL and header
mutability? Header
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 sol
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
To: oauth@ietf.org
Sent: Friday, February 1, 20
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: Torst
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
To: oauth@ietf.org
Sent: Thursday, January 31, 2013 6:
The draft should probably register a link relation type. I'd register it with
the others, but that draft is already in the individual submission pipeline.
From: Torsten Lodderstedt
To: Anthony Nadalin
Cc: "oauth@ietf.org"
Sent: Saturday, January 26, 2013 1
Not a problem for the client to request a type, but it may not get it.
From: "zhou.suj...@zte.com.cn"
To: Prabath Siriwardena
Cc: "oauth@ietf.org WG" ; William Mills
Sent: Sunday, January 20, 2013 9:38 PM
Subject: Re: Re: Re: [OAU
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
To: "oauth@ietf.org WG"
Sent: Sunday
That would work. Register a link relation property for supported signing
methods.
From: John Bradley
To: William Mills
Cc: Mike Jones ; "oauth@ietf.org"
Sent: Friday, January 4, 2013 4:09 PM
Subject: Re: [OAUTH-WG] December 27, 2012 OAuth Rel
radley
To: William Mills
Cc: Mike Jones ; "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.
Otherwise you are back to coming up with a way
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 validate
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
To: William Mills ; "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
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 OAuth
10x
Hi g
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 serve
n one value in the keying information.
From: Sergey Beryozkin
To: William Mills
Cc: ""
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 as I'm using it is a
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
To: William Mills
Cc: ""
Sent: Friday, December 21, 2012 3:15 AM
Subject: Re: [OAUTH-WG] Few questions about HOTK
"
To: William Mills
Cc: "" ; SergeyBeryozkin
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 and HOTK describe different properties of a token, and could
> both be us
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
Responses inline.
>
>From: Hannes Tschofenig
>To: William Mills
>Cc: Hannes Tschofenig ; "Tschofenig, Hannes (NSN -
>FI/Espoo)" ; ext Sergey >Beryozkin
>; "oauth@ietf.org"
>Sent: Tuesday, November 27, 2012 10:54
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."
To: William Mills
Cc: "Tschofenig, Hannes (NSN - FI/Espoo)" ; e
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 abo
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
To: Sergey Beryozkin
Cc: ""
Sent: Monday, November 26, 2012 10:28 AM
Subje
401 not 400
From: Justin Richer
To: Sergey Beryozkin
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 signaling regarding the validity of the refr
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 differen
The Authorization scheme name in the Authorization header tells you
From: Ib Lundgren
To: oauth@ietf.org
Sent: Sunday, November 18, 2012 8:57 AM
Subject: [OAUTH-WG] Identifying token type during protected resource access
Hey everyone,
http://tools.ietf.org
OK, I see the use case, although I don't find it particularly compelling.
From: Justin Richer
To: William Mills
Cc: Hannes Tschofenig ; Torsten Lodderstedt
; "oauth@ietf.org WG"
Sent: Tuesday, September 11, 2012 8:58 AM
Subject: Re: [OAUTH
I think a resource server might validly revoke a token, but that a client will
not.
-bill
- Original Message -
From: Hannes Tschofenig
To: William Mills
Cc: Hannes Tschofenig ; Torsten Lodderstedt
; Justin Richer ; "oauth@ietf.org
WG"
Sent: Tuesday, September 11, 20
> 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
To: Hannes Tschofenig
Cc: "oauth@ietf.org"
Sent: Monday, September 10, 2012 6:14 AM
Subject: Re: [OAUT
Revocation endpoint discovery can be handled through standard discovery
mechanisms. I don't think clients should request revocation (see earlier
message).
From: Hannes Tschofenig
To: "oauth@ietf.org WG"
Sent: Monday, September 10, 2012 5:25 AM
Subject: [OAU
Well, the only way the client would request revocation is if the client thinks
the token is compromised, e.g. that the client has done dumb stuff. In that
sense I think the client requesting revocation makes no sense.
I am also not in favor of token introspection endpoints at all, the client
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
To: William Mills
Cc: "oauth@i
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
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 wa
provide
comatibility.
-bill
From: Hannes Tschofenig
To: William Mills ; Hannes Tschofenig
Cc: O Auth WG
Sent: Tuesday, August 14, 2012 11:32 PM
Subject: Re: [OAUTH-WG] OAuth 1.0a
Re: [OAUTH-WG] OAuth 1.0a
Hi Bill,
On 8/15/12 9:16 AM, "ext Wi
From: Hannes Tschofenig
To: William Mills
Cc: Hannes Tschofenig ; Torsten Lodderstedt
; O Auth WG
Sent: Tuesday, August 14, 2012 10:49 PM
Subject: Re: [OAUTH-WG] OAuth 1.0a
Hi Bill,
how do you know that the outcome of the security discussions will unlikely be
different than MAC?
The views
.
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
To: William Mills
Cc: Hannes Tschofenig ; Mike Jones
; O Auth WG
Sent: Tuesday, August 14, 20
Yeah, I still need 1.0a to work which I was hoping to replace with MAC.
From: Mike Jones
To: William Mills ; Torsten Lodderstedt
Cc: O Auth WG
Sent: Tuesday, August 14, 2012 12:44 PM
Subject: RE: [OAUTH-WG] OAuth 1.0a
Agreed. Use Bearer now. If you
is unlikely 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
To: William Mills
Cc: Mike Jones ; O Auth WG
Sent: Tuesday, August 14, 2012 1
nt to make sure the SASL mechanism is build to properly handle signed auth
schemes and not just bearer (cookie) type.
-bill
From: Mike Jones
To: William Mills ; O Auth WG
Sent: Tuesday, August 14, 2012 12:28 PM
Subject: RE: [OAUTH-WG] OAuth 1.0a
What
What's the general opinion on 1.0a? Am I stepping in something if I refer to
it in another draft? I want to reference an auth scheme that uses signing and
now MAC is apparently going back to the drawing board, so I'm thinking about
using 1.0a.
Thanks,
-bill___
Thanks.
From: Mike Jones
To: William Mills ; Dick Hardt ;
"oauth@ietf.org WG"
Sent: Tuesday, August 14, 2012 11:43 AM
Subject: RE: [OAUTH-WG] Fwd: [IANA #596670] Protocol Action: 'The OAuth 2.0
Authorization Framework: Bearer Token Usa
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
To: "oauth@ietf.org WG"
Sent
rs are working on as well.
>>> 5) What is the threat you are concerned about?
>>>
>>> Ciao
>>> Hannes
>>>
>>> PS: I would heavily argue against standardize a security mechanism that
>>> offers weaker protection than bearer when the
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
To: William Mills
Cc: David Waite ; "oauth@ietf.org"
Sent: Friday, August 10, 2012 8:09 AM
Su
From: Hannes Tschofenig
To: William Mills
Cc: Hannes Tschofenig ; John Bradley
; "oauth@ietf.org"
Sent: Friday, August 10, 2012 12:01 AM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
Hi Bill,
thanks for the feedback. Le
on the current PKI that is SSL certificates we should do
that separately.
From: John Bradley
To: William Mills
Cc: David Waite ; "oauth@ietf.org"
Sent: Thursday, August 9, 2012 8:47 PM
Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-ma
nsaction, can offer integrity protection on all or part of an
>>HTTP request, and can provide replay protection.
>>
>>
>>-bill
>>
>>
>>
>>
>> From: John Bradley
>>To: William Mills
>>Cc: Dick Hardt ; "
Mostly it's around making sure you get the signature base string constructed
right in my experience.
From: Dick Hardt
To: William Mills
Cc: Dick Hardt ; "oauth@ietf.org"
Sent: Thursday, August 9, 2012 12:48 PM
Subject: Re: [OAUTH-WG] mistak
John Bradley
To: William Mills
Cc: Dick Hardt ; "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 of the MAC spec due to it
no linger having a editor.
T
: William Mills
Cc: "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 frustrating. MAC solves a set of
specific proble
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 an
Justin,
Count me in to help revive this and get it done.
-bill
From: Justin Richer
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 document is currently wit
(Routing this to Kitten WG)
I don't have much of a preference here, on the one hand I think a plaintext
hint is very reasonable, on the other I suspect people will be tempted to use
it for more than that which would be bad. In the HTTP space it's easy for
anyone using OAuth to put a plaintext
: William Mills
To: Hannes Tschofenig
Cc: "oauth@ietf.org"
Sent: Wednesday, July 11, 2012 9:52 AM
Subject: Re: [OAUTH-WG] Holder-of-the-Key for OAuth
Having re-read this I think I now understand how symmetric would work. In the
HOK model as I think of it we have 3 basic parts: opaque t
I agree that we don't want things like Internal Server Error (500) duplicated
in OAuth specific errors. The only thing I might add to 5.2 is something like
"Other HTTP status codes such as 500 (Internal Server Error) may be returned
with no OAuth specific parameters."
-bill
_
fact. The
relying endpoint would extract the secret from the token to check the
signature. For the PK case you don't have to encrypt the asserted key, which
is a little cheaper.
-bill
From: Hannes Tschofenig
To: William Mills
Cc: Hannes Tschofenig ; pr
OK, but why do you need holder-of-key then? I think holder-of-key gets
significantly weird in the symmetric key case. In the PKI case the token has
(public_key, token, signature(public_key, token, serversecret)). How will the
server assert something in the credential that's useful in place o
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"
To: Hannes Tschofenig ; OAuth WG
Sent: Monday, July 9,
Ah... sigh. I did reply yesterday, but never got connection information.
From: "Tschofenig, Hannes (NSN - FI/Espoo)"
To: William Mills ; Hannes Tschofenig
; OAuth WG
Sent: Monday, July 9, 2012 11:50 AM
Subject: RE: [OAUTH-WG] 'Finishing
Is this on? Is there a dial-in or hangout link?
From: Hannes Tschofenig
To: OAuth WG
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 invitation to the
o
I'll try to attend this.
From: Hannes Tschofenig
To: OAuth WG
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 invitation to the
oauth@ietf.org mailing li
Aesthetically this makes my tummy hurt...
That said, I think it will work, and I'm willing to go with it.
>
> From: Mike Jones
>To: George Fletcher
>Cc: "oauth@ietf.org"
>Sent: Friday, June 15, 2012 10:30 AM
>Subject: Re: [OAUTH-WG] Dynamic clients, URI, an
+1
>
> From: Eran Hammer
>To: Mike Jones ; "oauth@ietf.org WG
>(oauth@ietf.org)"
>Sent: Thursday, June 14, 2012 11:32 PM
>Subject: Re: [OAUTH-WG] Section 7.2
>
>
>
>WFM.
>
>This will be the new text for 7.2 unless someone has any additional feedback
>or c
We might be able to combine these, but to me it really does make sense to have
one registry for OAuth 2 core extensions to the frameowrk and one for the auth
profiles. The downside of this would be duplication between the two. If we
think there will be significant overlap then I think they sho
Updated for examples, the editorial issues like replacing link header for lrdd
where it appears, fixing authenticate->authorize.
Thanks for the feedback so far.
-bill
--
A new version of I-D, draft-wmills-oauth-lrdd-01.txt
has been successfully submitted by William Mi
I've incorporated a number of changes and added examples. Thanks to all for
the feedback. I can do a new draft any time if that's useful.
-bill
- Original Message -
> From: Peter Saint-Andre
> To: William Mills
> Cc: O Auth WG ; Apps Discuss
> Sent: Wednesd
ported and perhaps others?
-bill
- Original Message -
> From: Eve Maler
> To: William Mills
> Cc: Goix Laurent Walter ; Peter
> Saint-Andre ; O Auth WG ; Apps Discuss
>
> Sent: Wednesday, June 13, 2012 11:38 AM
> Subject: Re: [OAUTH-WG] [apps-discuss] OAuth
Worthwhile to change the document title?
Examples are easy, can do.
- Original Message -
> From: Eran Hammer
> To: William Mills ; O Auth WG ; Apps
> Discuss
> Cc:
> Sent: Wednesday, June 13, 2012 9:03 AM
> Subject: RE: [OAUTH-WG] OAuth discovery registrati
; To: Peter Saint-Andre ; William Mills
>
> Cc: O Auth WG ; Apps Discuss
> Sent: Wednesday, June 13, 2012 9:44 AM
> Subject: R: [apps-discuss] [OAUTH-WG] OAuth discovery registration.
>
>T hank you William for this initiative.
>
> I had similar concerns than Peter on authn v
o get this into the core OAuth 2
spec, and it doesn't really fit in the WebFinger. Submission info provided
below.
-bill
A new version of I-D, draft-wmills-oauth-lrdd-00.txt
has been successfully submitted by William Mills and posted to the
gt;>
>>>
>>>On 12 Jun 2012, at 21:08, Eran Hammer wrote:
>>>
>>>The only distinction I would make is between removing flexibiliy to
>>>proactively enabling future extensibility. I would stop short of perscribing
>>>encoding in order to fit
OK. I'll do that. Not hard.
Will folks want to discuss the individual submission here? Or will that be in
apps-discuss?
Is it informational if it does IANA registry actions?
Thanks,
-bill
>
> From: Derek Atkins
>To: William Mills
If endpoint discovery is to be via WebFinger (LRDD/XRD) we need there relations
defined for the OAuth endpoints I had that in
http://tools.ietf.org/id/draft-ietf-kitten-sasl-oauth-00.txt section 7.3, but
I've ripped all the discover stuff out of there.
This seems more appropriate in the OAuth
id of type
uri_client_id MUST NOT use HTTP Basic client authentication."?
-bill
>
> From: Eran Hammer
>To: George Fletcher
>Cc: Mike Jones ; William Mills
>; Hannes Tschofenig ; Julian
>Reschke ; "oauth@ietf.org"
>Sent:
ng.
-bill
>
> From: Eran Hammer
>To: Mike Jones ; William Mills
>; Hannes Tschofenig ; Julian
>Reschke
>Cc: "oauth@ietf.org"
>Sent: Tuesday, June 12, 2012 11:39 AM
>Subject: RE: [OAUTH-WG] Discussion needed on username and password ABNF
>de
1 - 100 of 309 matches
Mail list logo
