Yes, it would be helpful (and I think reasonable) to have an explanation of
why the process was changed so wildly from the past twenty-six drafts.
--David
On Fri, Jun 8, 2012 at 9:09 PM, Franklin Tse wrote:
> I think the chairs should clarify and explain, via this mailing list,
>
> 1. Whether t
Regardless of how we got here, just feels strange to have a
strong recommendation against the way the protocol is actually being used.
I completely understand that standards live on for well over eighteen
months (or five years if we start with OAuth 1.0) but this feels like we're
just going to end
I'm confused by this change given the access_token (or oauth_token)
parameter being the most widely deployed usage of the protocol over the
past eighteen months:
* https://developers.facebook.com/docs/reference/api/
* https://developers.google.com/accounts/docs/OAuth2WebServer#callinganapi
* ht
Honestly still trying to fully wrap my head around what's going on here
since it seems far more complex than the threads are alluding to. In any
case, does Mike's text address what Eran brought up as needed in the thread
Hannes referenced or is Eran wrong?
The core spec currently provides full gui
Hey Mike, I think this has been said a few times by Eran and Peter but
you really need to propose actual sentences that you want to see
included in the specification at this point. Saying "I think it should
be clearly explained" isn't actionable text.
That said, I strongly don't believe this is an
So far Facebook has used `state` in examples within our documentation
and strongly recommend it but have not gone so far as to mandate it.
Quoting https://developers.facebook.com/docs/authentication/:
> Cross site request forgery is an attack in which an trusted (authenticated
> and authorized) us
Agreed as well on this being implementation specific. Also don't
remember ever seeing anonymity mentioned as a use case.
On Thu, Aug 11, 2011 at 4:28 PM, Eran Hammer-Lahav wrote:
> I strongly agree. I don't see what value there is in discussing anonymity
> which brings identity into the spec wit
I was trying to keep http://wiki.oauth.net/w/page/25236487/OAuth-2 up
to date but haven't in awhile.
On Fri, Jun 24, 2011 at 10:02 AM, Eve Maler wrote:
> Zero response from the other list. Any suggestions from folks here?
>
> Begin forwarded message:
>
>> From: Eve Maler
>> Date: 20 June 2011 4
+1 Eran
On Fri, Jun 17, 2011 at 12:46 AM, Eran Hammer-Lahav wrote:
> OAuth has been successful because of its simple architecture and because it
> is based on actual deployment experience. Offering multi-token responses
> would be premature standardization. I am not convinced that adding it lat
Bearer token doesn't exist within the core spec around getting an
access token. The term that is used is "access token".
On Tue, Jun 14, 2011 at 8:12 AM, Bill wrote:
> On 10/06/11 17:45, David Recordon wrote:
>>
>> I think it's vital to have the GET and POS
ample.com
>>> Authorization: Bearer vF9dft4qmT
>>>
>>> Is the proposal then that we have:
>>>
>>> 1. GET /resource?access_token=vF9dft4qmT
>>> 2. POST /resource
>>>
>>> access_token=vF9dft4qmT&...
>>
George, Doug and Eran are you alright with the Bearer token spec using
the parameter name "access_token" as well?
On Wed, Jun 8, 2011 at 4:50 PM, Marius Scurtescu wrote:
> On Wed, Jun 1, 2011 at 1:14 PM, Mike Jones
> wrote:
>> If you can drive a consensus decision for the name "access_token",
s here [2].
>
> Thanks,
> George
>
> [1] http://www.ietf.org/mail-archive/web/oauth/current/msg05497.html
> [2] http://www.ietf.org/mail-archive/web/oauth/current/msg05881.html
>
> On 5/28/11 12:30 PM, David Recordon wrote:
>
> Did a full read through of draft 16 and th
at, May 28, 2011 at 10:14 AM, Doug Tangren wrote:
>
> -Doug Tangren
> http://lessis.me
>
>
> On Sat, May 28, 2011 at 12:30 PM, David Recordon
> wrote:
>>
>> Did a full read through of draft 16 and the bear token spec with Paul
>> yesterday afternoon in orde
In sections 4.1.3, 4.3.2, 4.4.2 and 6 there's a list of parameters
included within the request and then the sentence, "The client
includes its authentication credentials as described in Section 3."
Reading through the spec yesterday afternoon with Paul, we first
thought that client_secret was remov
Did a full read through of draft 16 and the bear token spec with Paul
yesterday afternoon in order to do a manual diff from draft 10. The
point Doug raised was actually confusing. Throughout the core spec
it's referred to as access_token but then becomes bearer_token upon
use.
Just thinking throug
If you're planning to attend in person then you'll want to head to
1050 Page Mill Road in Palo Alto. There's a bunch of parking behind
the building so feel free to park anywhere in that lot. You'll then
want to head to the lobby of building 1 which is the largest; the
lobby is on the Page Mill side
Yes and yes. Just please add (remote) to your name on the wiki page.
On Wed, May 11, 2011 at 8:38 AM, Doug Tangren wrote:
> 2 questions?
> 1. Would there be a conference line one could dial into remotely? (I'm in
> New York City)
> 2. Is this open to implementors of the spec in addition to it's a
On Tue, May 10, 2011 at 11:17 PM, Barry Leiba wrote:
>
> If you post the venue details to this thread, when you have them, I'll
> update the wiki:
> http://trac.tools.ietf.org/wg/oauth/trac/wiki/InterimMeeting
Sure, it's 1050 Page Mill Road in Palo Alto and then head to the lobby
of building 1
Anyone else noticed that they overlap each other this year? :-/
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
inal Message-
>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
>> Of David Recordon
>> Sent: Friday, April 22, 2011 2:26 PM
>> To: Melinda Shore
>> Cc: Barry Leiba; OAuth WG
>> Subject: Re: [OAUTH-WG] OAuth Interim Meeting
>>
Hey Barry, I'm confused. This thread is full of comments. Is there an
updated charter which addresses them?
On Sun, May 8, 2011 at 3:51 PM, Barry Leiba wrote:
> We've had a week and a half for comment, and there've been no
> significant suggestions for changes to the charter proposal, so I'm
> go
I agree with Eran as well that the focus should be on finalizing 2.0
and then future work can occur in new working groups. We're so close!
I keep telling people throughout the industry that the spec hasn't
changed technically in months but they keep asking when it's going to
be a final RFC.
On Th
I can setup audio and video conferencing if it's at Facebook.
On Fri, Apr 22, 2011 at 12:13 PM, Melinda Shore wrote:
> I'm unable to attend in person but I'm hoping that remote participation
> will be an option - any hope of that?
>
> Thanks,
>
> Melinda
>
Happy to host in Palo Alto.
On Fri, Apr 22, 2011 at 8:01 AM, Hannes Tschofenig
wrote:
> Hi all,
>
> we are planning to hold a 1-day interim meeting for the OAuth working group.
>
> Date: 23rd May, 2011 (9am - 6pm)
> Location: Mountain View, CA, US
> Host: Tbd.
> Agenda: Discussion of remaining op
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 was adopting. Under-defined extension
points don't make t
I can't say I understand this change when we're so close to being finished.
On Fri, Apr 1, 2011 at 12:25 AM, Peter Saint-Andre wrote:
> As discussed in the WG session at Prague just now, in discussion with
> the Security Area Directors I have decided to move the OAuth Working
> Group from the App
If this is changed to a MUST, Facebook will be in violation of the
specification moving forward. It is untenable to require all of our
*client* developers to implement TLS endpoints though we certainly
support developers who wish to do so. This is very different than
offerring our entire API (and n
ny, it is very important to
> others, so bear with me. I want to make sure we give everyone the proper
> recognition they deserve.
>
>
>
> - Authors
>
>
>
> The document currently lists 1 editor (Eran Hammer-Lahav) and 2 authors
> (David Recordon, Dick Hardt). T
4.3.1 as "[[ Add mechanism for extending error
> codes ]]".
>
> It's there to provide a coordination mechanism among OAuth-related
> specifications so that different specs use the same errors for the same thing.
>
> -- Mike
>
Cool!
On Mon, Mar 14, 2011 at 7:35 PM, Marius Scurtescu wrote:
> The announcement:
> http://googlecode.blogspot.com/2011/03/making-auth-easier-oauth-20-for-google.html
>
> The documentation page:
> http://code.google.com/apis/accounts/docs/OAuth2.html
>
> Other than the core spec it implements:
>
I still haven't seen an explanation of what this registry accomplishes
or why it's become needed in the past few weeks.
--David
On Fri, Mar 11, 2011 at 11:04 PM, Mike Jones
wrote:
> As you know, the OAuth 2.0 Bearer Token draft -03 established the OAuth
> Errors Registry to increase interoperab
Sorry, read the previous version of this poll. Meant #2 in this one.
On Tue, Feb 8, 2011 at 10:08 PM, David Recordon wrote:
> #1
>
> On Tue, Feb 8, 2011 at 3:04 PM, Mike Jones
> wrote:
>> Given that people are clearly voting to change the bearer token scheme name,
>>
#1
On Tue, Feb 8, 2011 at 3:04 PM, Mike Jones wrote:
> Given that people are clearly voting to change the bearer token scheme name,
> but that there is also significant discussion asking for “OAuth2” to be part
> of the name, I’d like to settle the matter by vote on the list. Please vote
> for o
Also #1. While I feel for existing implementations of "OAuth2" by
itself, it's not the best name for this specific piece of
functionality and Facebook too has a final migration server side to
make for other features in the spec which weren't finalized when we
implemented them.
On Thu, Feb 3, 2011
Explicitly saying, "The assertion format, the process by which the assertion
is obtained, and the method of validating the assertion are defined by the
assertion issuer and the authorization server, and are beyond the scope of
this specification" seems to reinforce the point about this being
unders
Seems good enough to me. +1 to removing it so that it will become fully
fleshed out in a useful manner.
On Sat, Jan 15, 2011 at 11:32 AM, Eran Hammer-Lahav wrote:
> You still need to define it. The two parameters don’t accomplish anything
> since you can’t use them without a more detailed specif
Added you to http://wiki.oauth.net/w/page/OAuth-2. Any parts of the
implementation what were challenging?
On Tue, Oct 26, 2010 at 5:27 PM, Olivier POITREY wrote:
> Hi,
>
> I'm proud to announce that Dailymotion released the first beta of its new
> API fully based on OAuth 2.0 draft 10. We are s
Hey Hannes, I'd like to at least explain my reasoning behind not planning to
go to the China meeting because it really isn't restrictions around travel.
This is likely inpolitic to say, but it's because of how much of a waste of
my time the LA meeting was. The LA meeting contained numerous people w
I haven't seen one. Have been trying to keep track of all the implementation
on http://wiki.oauth.net/w/page/OAuth-2.
On Tue, Oct 12, 2010 at 9:33 AM, William Mills wrote:
> Is there a C/C++ opensource implementation yet I can use for the
> reference implementation of the SASL mechanism yet?
>
If you know me then you'll know that I'm generally one of the last people to
talk about Alice and Bob. That said, there are a lot of technical proposals
flying across the list with very little shared understanding of the
problem(s) we're trying to solve.
>From what I've seen there are two distinct
t the JWT proposal is well under way, what I would like to
> make sure is that we merged in with your proposal
>
>
>
> *From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf
> Of *Dirk Balfanz
> *Sent:* Monday, September 27, 2010 9:13 AM
> *To:* David
I'm a bit confused between the relationship of Nat's I-D and the documents
you and Mike recently posted. Is the goal to have one I-D? Nat's seems to
have fewer options and different modes which makes it easier to read and
understand.
On Mon, Aug 30, 2010 at 11:47 AM, Yaron Goland wrote:
> BTW,
I thought the discussion from June had most people not
needing encryption and an extra envelope. Given how Mike wrote this spec is
seems like supporting encryption with an extra envelope is possible, but
shouldn't be required if all you're doing is signing.
On Sun, Sep 26, 2010 at 9:55 PM, Dick Ha
+1 on core
On Thu, Sep 23, 2010 at 6:43 PM, Eran Hammer-Lahav wrote:
> Since much of this recent debate was done off list, I'd like to ask people
> to simply express their support or objection to including a basic signature
> feature in the core spec, in line with the 1.0a signature approach.
>
>
I'd like to see us finish Core before considering re-chartering. :)
But to your original question. I'm interested in the UX extension (said I'd
edit), device flow (said I'd edit), and the OpenID Connect work which
encompasses dynamic registration and likely artifact binding (also editing
but outsi
Hey Jim, you should join the OpenID Connect work. We're layering
decentralized identity on top of OAuth 2.0.
- http://openidconnect.com/
- http://lists.openid.net/mailman/listinfo/openid-specs-connect
On Fri, Sep 10, 2010 at 7:22 PM, Jim Pravetz wrote:
> Thanks for the explanation, William.
>
One of the things I really liked about WRAP (which we've largely preserved
in 2.0) is more specific flows for the different use cases. I generally
don't think that we should make this anymore generic than it already is. I
do think that merging the assertion type into the grant type parameter is
the
I like that this also collapses the grant_type=assertion and
assertion_type=foo.
On Thu, Sep 2, 2010 at 2:28 PM, Eran Hammer-Lahav wrote:
> Yes.
>
> -Original Message-
> From: Justin Richer [mailto:jric...@mitre.org]
> Sent: Thursday, September 02, 2010 2:27 PM
> To: Eran Hammer-Lahav
>
me problem as above, where all instances of the same client look
> identical to the end user.
>
> All that this proposal really does is give us a standard slot to put
> identification information for the different tokens.
>
> -- justin
>
> On Fri, 2010-08-27 at 22:06 -0400, Davi
ocess?
>
Yes. Given that the client is asking for a greater scope, the user would
have to authorize it. A client can ask for a decreased scope when refreshing
a token (which makes similar assumptions about how scope works as I have
been in this email).
regards,
> Torsten.
>
> Am 2
e authz server the screen
> orientation and available size?
>
> regards,
> Torsten.
>
> Am 12.07.2010 21:51, schrieb David Recordon:
>
> I wrote this draft last month based on discussions on the mailing list, the
> OpenID user experience extension (which Facebook, G
on?
>
> -- Justin
>
> * http://www.ietf.org/mail-archive/web/oauth/current/msg03717.html
>
> On Fri, 2010-08-27 at 16:23 -0400, David Recordon wrote:
> > Given our implementation experience, an iPad should use "popup" as
> > it's a full web browser on
ime I'd like to request that it move to become a Working Group
item. I'm am happy to continue acting as the editor.
--David
On Thu, Jul 15, 2010 at 9:41 PM, David Recordon wrote:
> Even better, thanks!
>
>
> On Thu, Jul 15, 2010 at 2:31 PM, Michael D Adams wrote:
>
&
And to follow that up, I'd like to request that this draft moves to become a
Working Group item. I'm am happy to continue acting as the editor.
On Fri, Aug 27, 2010 at 8:23 PM, David Recordon wrote:
> Given our implementation experience, an iPad should use "popup" as it
wishes to do so
moving forward.
Thanks,
--David
On Mon, Jul 12, 2010 at 10:39 PM, David Recordon wrote:
> The ability to upgrade OAuth 1.0 tokens and secrets to OAuth 2.0 access
> tokens has come up on the list a few times. Attached is a draft assertion
> format which allows a client to
available for display so the server can make a smarter presentation.
> Desktop, netbook, tablet, and mobile screen dimensions vary widely
> now."
>
> Marius
>
>
>
> On Mon, Jul 12, 2010 at 12:51 PM, David Recordon
> wrote:
> > I wrote this draft las
I think that the meaning here is that the client can handle the HTTP
redirect back from the authorization server. Not that the authorization
server is making a HTTP request directly to it. Agreed that it could be
clarified. :)
On Wed, Aug 25, 2010 at 9:19 AM, Stuebner, Christian (extern) <
c.stue
Giving scope basic structure (space delimitated) allows any app developer to
store a list of scopes which they have and compare any desired scopes to
that list. While the meaning of each scope is not standardized, it allows
for this sort of simple operation on scope. 5.2.1 also defines how a
protec
Luke's point still holds true of the core spec needing to allow a 200 status
code on an error in this scenario. I'd also rather see this as part of the
core spec as it reduces the number of things that implementors will need to
read for common use cases.
--David
On Tue, Aug 17, 2010 at 9:06 AM,
hile the former I think of it more as a
> means of allowing for stronger forms of client authentication than
> just a client password/secret.
>
> I guess both could be used in a two-legged style interaction (or used
> together) and maybe that's where it starts to get confusing.
I've only been half following the recent assertion threads for this
exact reason. I don't understand how these proposals are going to be
used and worry about any additional complexity added to the spec.
--David
On Thu, Aug 12, 2010 at 1:24 PM, Chuck Mortimore
wrote:
> Personally, I’d first like
ot; where access token will not be passed in a URL. It might require using
> dynamic pages generated by a server, but if somebody wants to implement a
> more secure solution, they'll at least have a choice.
>
>
>
>
> From: Luke Shepard
> To: Oleg Gryb
> Cc: Torsten
http://gowalla.com/api/docs/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
The thread wondered a bit but Brian's summary here seems to be what most
people were advocating for. Is there enough consensus to have Draft 11
reflect it?
Thanks,
--David
On Wed, Jul 14, 2010 at 10:04 AM, Brian Eaton wrote:
> I can't parse this diagam, but here's my take:
>
> - web server flo
A richer history API is also coming as a part of HTML5.
http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html
On Mon, Aug 2, 2010 at 12:47 PM, Brian Eaton wrote:
> On Mon, Aug 2, 2010 at 9:23 AM, Oleg Gryb wrote:
> >
> > What about browsing history? I've just run the JSP belo
That matches my understanding as well.
--David
On Mon, Aug 2, 2010 at 1:33 PM, Eran Hammer-Lahav wrote:
> General discussions on the list and during the interim meeting.
>
> EHL
>
> > -Original Message-
> > From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
> > Sent: Monday, Aug
Yes, all of these all seem like the right set of use cases. I'm not sure if
I'll have much time to devote to them over the next few months though.
--David
On Mon, Aug 2, 2010 at 2:14 PM, William Mills wrote:
> Client discovery can be useful for presenting a nicer user experience in
> token man
Yes, the HTTP request that the browser finally made was:
> GET / HTTP/1.1
Host: www.google.com
The fragment wasn't sent by the browser to the server.
--David
On Sun, Aug 1, 2010 at 5:12 PM, Oleg Gryb wrote:
> Here is an example with Location header. I don't see URI with access token
> been
I don't have a need for anything beyond the scope parameter here.
On Thu, Jul 22, 2010 at 3:07 PM, Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:
> no one else in the group having an opinion on this topic?
>
>
>
> Am 15.07.2010 20:14, schrieb Marius Scurtescu:
>>
>>> On Thu, Jul 15, 2010
What is the rechartering discussion?
Thanks,
--David
On Wed, Jul 21, 2010 at 3:18 AM, Hannes Tschofenig <
hannes.tschofe...@gmx.net> wrote:
> Hi all,
>
> please find the latest agenda at:
> http://www.ietf.org/proceedings/78/agenda/oauth.txt
>
> Make sure that you read to provide input during t
I've always found "client password" to be a confusing term.
On Fri, Jul 16, 2010 at 12:26 PM, Brian Eaton wrote:
> On Fri, Jul 16, 2010 at 12:22 PM, Brian Campbell
> wrote:
> > +1 for something different but not "client password" as sounds like it
> > would preclude other methods of client aut
Even better, thanks!
On Thu, Jul 15, 2010 at 2:31 PM, Michael D Adams wrote:
> On Thu, Jul 15, 2010 at 2:11 PM, David Recordon
> wrote:
> > On Thu, Jul 15, 2010 at 1:36 PM, Zeltsan, Zachary (Zachary)
> >> “The client makes the following request at an arbitrary but reasonabl
HOULD requirement, while in section 1.5 the MUST
> requirement is used. Should not the requirement be the same in both places?
>
Changed this should to a must.
>
>
> Zachary
>
>
> --
>
> *From:* oauth-boun...@ietf.org [mailto:oauth-
t used by
the application's web servers would still be secure.
> Thanks,
> George
>
> On 7/15/10 3:47 PM, David Recordon wrote:
>
> I've broken the device profile out of draft 06 so that it now lives in a
> separate document as an extension and have updated i
I've broken the device profile out of draft 06 so that it now lives in a
separate document as an extension and have updated it to fit into the draft
10 structure. It defines a new "device endpoint" for the initial setup
request where the client gets the two codes and URL. It then uses the
existing
Given that OAuth discovery hasn't been written yet, how would an OAuth 1.0
client know about a 2.0 protected resource in the first place?
On Thu, Jul 15, 2010 at 11:33 AM, John Kemp wrote:
> On Jul 15, 2010, at 9:07 AM, Eran Hammer-Lahav wrote:
>
> > I would like people to raise their hand and
I thought this topic had been beaten to death before. An OAuth 1.0 protected
resource request includes a variety of oauth_ parameters whereas OAuth 2.0
just has oauth_token.
--David
On Thu, Jul 15, 2010 at 10:12 AM, Brian Eaton wrote:
> On Thu, Jul 15, 2010 at 7:59 AM, Justin Richer wrote:
>
I caught up on the thread and with Luke yesterday afternoon and am fine with
the user-agent flow using the fragment in the token and code case.
On Wed, Jul 14, 2010 at 10:04 AM, Brian Eaton wrote:
> I can't parse this diagam, but here's my take:
>
> - web server flow should always return just a
I support immediate and a form of forced auth (ala OpenID's PAPE) but not in
the core spec. They both should be part of an identity extension.
On Tue, Jul 13, 2010 at 9:51 AM, William Mills wrote:
> I agree with Colin that some form of force_auth is needed. I haven't
> read enough on the "imm
On Tue, Jul 13, 2010 at 1:06 AM, Luke Shepard wrote:
> I just read this bit:
>
>If the response type is "code_and_token", the authorization server
>adds the "code" and "state" parameters to the redirection URI query
>component and the "access_token", "scope", and "expires_in" to the
>
Obviously I'm fine with this being merged into core if that's what the group
wants to do. :)
On Mon, Jul 12, 2010 at 5:49 PM, Manger, James H <
james.h.man...@team.telstra.com> wrote:
> .David,
>
>
>
> > I'd like this draft [draft-recordon-oauth-v2-ux-02.txt] to become a
> working group documen
onal considerations beyond those described within the OAuth
2.0 Protocol.
5. Normative References
[I-D.ietf.oauth-v2]
Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, "The
OAuth 2.0 Protocol", Jun 2010.
[RFC2119] Bradner, B., "Key words
OAuth 2.0 Protocol", Jun 2010.
[RFC2119] Bradner, B., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119.
[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
Languages", BCP 47, RFC
On Sat, Jul 10, 2010 at 2:22 PM, Dick Hardt wrote:
> Obviously anything besides what you need for your use case adds complexity.
> The question is: are you willing to accept some complexity so that it works
> for use cases than yours? If not, then perhaps you should just define your
> own signatu
On Sat, Jul 10, 2010 at 1:29 PM, Dick Hardt wrote:
> On 2010-07-10, at 1:21 PM, David Recordon wrote:
>
> On Sat, Jul 10, 2010 at 11:00 AM, Dick Hardt wrote:
>
> * the signature comes before the payload
>> * we used the key 'algorithm' instead of 'alg'
On Sat, Jul 10, 2010 at 11:00 AM, Dick Hardt wrote:
> On 2010-07-10, at 9:58 AM, Paul Tarjan wrote:
>
> Hi OAuthers,
>
> First of all, I think I should introduce myself. I work at Facebook on the
> Platform team (anything not facebook.com). Before this I was at Yahoo!
> doing SearchMonkey (semant
B
On Thu, Jul 8, 2010 at 9:29 AM, David Recordon wrote:
> I'm honestly trying to decide myself and a few other people are in similar
> situations. Thus a poll:
> A) Yes, I'm going to be in Maastricht
> B) Maybe, depends on the number of OAuth WG members going
> C) May
I'm honestly trying to decide myself and a few other people are in similar
situations. Thus a poll:
A) Yes, I'm going to be in Maastricht
B) Maybe, depends on the number of OAuth WG members going
C) Maybe, depends on some other reason
D) No
If you're missing context, in a few weeks it is the IETF
Seems like adding, "It's RECOMMENDED that this parameter be included if the
access grant's scope differs from the requested scope." would be useful
implementation advice in 3.1.
On Fri, Jul 2, 2010 at 9:27 AM, Eran Hammer-Lahav wrote:
> Scope is an optional feature of a protocol. The server is f
I'm also of the opinion that a protected resource can use the request
parameters to differentiate between 1.0 and 2.0.
On Sat, Jul 3, 2010 at 3:27 AM, Rob Richards wrote:
> On that note are there any guidelines, howtos, etc.. on writing a spec?
>
I'd recommend focusing on just writing the text a
For #2, if an extension defines required parameters then you're not
supporting the extension if you ignore them. Or am I missing something?
On Mon, Jun 28, 2010 at 5:59 PM, Eran Hammer-Lahav wrote:
> There are 3 general ways to deal with this:
>
>
>
> 1. Break on unrecognized parameters – this t
If we have both error_code and error_description, why is an error_uri
needed? (I'm not finding anything when I search the list for
'error_uri'.)
On Tue, Jun 22, 2010 at 1:05 PM, Eran Hammer-Lahav wrote:
> There was also a suggestion by Brian to add an error_uri for additional
> information.
>
>
kinw_dp_ke?ie=UTF8&m=AG56TWVU5XWC2&qid=1277236054&sr=8-1
> -- Dick
>
> On Tue, Jun 22, 2010 at 12:20 PM, David Recordon
> wrote:
>>
>> All of the OAuth 1.0 implementations which I'm aware of either have
>> the server provide a shared secret to the cli
All of the OAuth 1.0 implementations which I'm aware of either have
the server provide a shared secret to the client or the client upload
their public key to the server.
In the case of the server providing a shared secret to the client,
what would the value of key_id be?
In the case of a client u
btw, I wrote a very naive PHP sample. http://gist.github.com/448164
On Mon, Jun 21, 2010 at 11:03 PM, David Recordon wrote:
> Thanks for writing this. A few questions...
>
> Do we need both `issuer` and `key_id`? Shouldn't we use `client_id`
> instead at least for OAuth?
>
Thanks for writing this. A few questions...
Do we need both `issuer` and `key_id`? Shouldn't we use `client_id`
instead at least for OAuth?
Can we write out algorithm instead of `alg`?
How do you generate the body hash?
Does "websafe-base64-encoded" mean that I can't just blindly use my
languag
Sure, a refresh token as well depending on the AS implementation.
On Thu, Jun 17, 2010 at 11:17 AM, Marius Scurtescu
wrote:
> On Thu, Jun 17, 2010 at 11:09 AM, Eran Hammer-Lahav
> wrote:
>> We added an optional authorization code which can only be used after
>> exchanging it for an access toke
ined case, token_and_code. I am not opposed
> to it, but I think it would help us wrap our heads around it if a
> detailed use case was presented.
>
> Thanks,
> Marius
>
>
>
> On Wed, Jun 16, 2010 at 11:05 PM, Eran Hammer-Lahav
> wrote:
>> This is a joint proposal fr
document the interactions separately, but it's also
become more clear around what servers need to implement given the
overlap.
--David
On Wed, Jun 16, 2010 at 11:05 PM, Eran Hammer-Lahav wrote:
> This is a joint proposal from David Recordon and me:
>
> ** Background:
>
> The latest
1 - 100 of 230 matches
Mail list logo
