On 2010-05-16, at 5:20 PM, Manger, James H wrote:
> Dick,
>
>> James: An important capability of the refresh token is that it *can* be a
>> self contained token in that is not an id, but a signed token that can be
>> examined and acted upon on presentation.
>
> Defining refresh_token as a URI
The image can be protected by both. Do you expect OAuth to be used with user
present in the browser?
On 2010-05-17, at 11:20 PM, Eran Hammer-Lahav wrote:
> Why can’t an image be protected with both Basic and OAuth? In this case the
> browser is the OAuth client.
>
> EHL
>
Frustration devs have with URL encoding. This is the core motivation to using
JSON as the AS response format.
-- Dick
Begin forwarded message:
> From: Andrew Badera
> Date: May 23, 2010 2:57:44 PM PDT
> To: twitter-development-t...@googlegroups.com
> Cc: oa...@googlegroups.com
> Subject: [oaut
On 2010-05-23, at 8:40 AM, Eran Hammer-Lahav wrote:
> But back to my original email, what are the use cases for 'immediate' without
> identity?
The client may not have any indication of which user it is, but want to check
if it is a user they already know. They can do a check immediate, get the
>> -Original Message-
>> From: Dick Hardt [mailto:dick.ha...@gmail.com]
>> Sent: Sunday, May 23, 2010 8:01 PM
>> To: Eran Hammer-Lahav
>> Cc: Torsten Lodderstedt; OAuth WG (oauth@ietf.org)
>> Subject: Re: [OAUTH-WG] 'immediate' without identity
>
On 2010-05-24, at 8:55 AM, Eran Hammer-Lahav wrote:
>
>
>> -Original Message-----
>> From: Dick Hardt [mailto:dick.ha...@gmail.com]
>> Sent: Monday, May 24, 2010 7:35 AM
>> To: Eran Hammer-Lahav
>> Cc: OAuth WG (oauth@ietf.org)
>> Subject: R
On 2010-05-24, at 4:55 PM, Marius Scurtescu wrote:
> And to add to this, this example shows that encoding is hard, JSON
> only solves decoding (in most cases, but not all).
JSON solves encoding and decoding with the same library.
>
> For all direct requests clients still need to encode and wit
Not sure why you want to pull the OAuth token parameters from the Kerberos
token.
Are you envisioning the Protected Resource is a Kerberos Client?
On Mon, May 24, 2010 at 9:31 AM, Thomas Hardjono wrote:
>
> I'm still a newbie to the OAuth and WRAP discussions, so please bear with
> me.
>
> In
The access token is not in the string that is signed. Is this a mistake or am I
missing something?
-- Dick
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Are you referring to my OpenID v.Next NewSocialService scenario?
What issues do you see doing this in v.Next rather than OAuth?
Using OpenID allows the client/RP to only discover the user's OP, which
knows where the user's calendar / address book is.
Having the OP as an intermediary allows it to
Raffi: would you care to elaborate on Twittter's use case?
On 2010-05-27, at 12:41 PM, Raffi Krikorian wrote:
> sorry to jump in late here - but i would also be interested in making
> signatures simple(r) to keep them in the core spec. i would be very
> interested in helping out on that front
I think so. In WRAP the verification code was RECOMMENDED one time use.
On 2010-05-30, at 9:38 AM, Andrew Arnott wrote:
> I was reviewing 3.6.2. Client Requests Access Token and it occurred to me
> that there's no requirement in the spec (that I can find) that a given
> callback URI and verifi
I don't recall any discussion at the level of detail that Torsten is asking
about.
My inclination would be the Client would include the what was returned in
WWW-Authenticate in the access request call.
On Tue, Jun 1, 2010 at 11:47 AM, Peter Saint-Andre wrote:
> We discussed this a bit at the int
The Assertion Flow is for the AS to act as an STS where one token is
exchanged for another. This allows the PR to not have to worry about
different kinds of tokens and to only deal with tokens issued by an AS.
Lisa: a real world example of your use case would make it easier for how you
got to the
On 2010-06-03, at 7:54 AM, Thomas Hardjono wrote:
> Dick, Brian,
>
> Thanks for the clarification.
>
> - Is the Assertion Flow designed only for the STS,
> or can it be used with other "identity providers" (non-WSS).
It can be used with any tokens. I use the STS term to clarify the design
pat
On 2010-06-03, at 8:20 AM, Peter Saint-Andre wrote:
> On 6/3/10 8:54 AM, Thomas Hardjono wrote:
>
>> PS. Compared to the details of RFC4120 and even
>> to the old ISAKMP in the IETF, the current
>> OAuth2.0 draft-05 spec appear to be a high-level framework
>> that needs to be instantiated/profil
On Fri, Jun 4, 2010 at 8:23 AM, Justin Richer wrote:
> > We should solve one problem at a time. It's easy to layer structure
> > on top of an opaque blob in a separate spec.
>
> +1 to this. Token structure seems like a nice idea, but it's outside
> what should be dictated by the OAuth spec. We wa
On Fri, Jun 4, 2010 at 8:00 AM, Luke Shepard wrote:
>
> On Jun 4, 2010, at 7:19 AM, George Fletcher wrote:
>
> > On 6/4/10 9:53 AM, Luke Shepard wrote:
> >>
> >> Having a single resource server that works with multiple independent
> auth servers is not in scope for OAuth. That said, there's nothi
+1 (just in case that was not clear from my other emails :)
On 2010-06-04, at 8:57 AM, Torsten Lodderstedt wrote:
> +1 for an optional "token_format" attribute/parameter
>
> Am 04.06.2010 17:21, schrieb John Kemp:
>> Hi Luke,
>>
>> On Jun 4, 2010, at 11:00 AM, Luke Shepard wrote:
>>
>>
>>>
s via a separate spec
> > 4. OAuth 2.0 should consider specifying an additional, optional parameter
> that is opaque to the client but identifies the "token format"
> >
> > Thanks,
> > George
> >
> >
> > On 6/4/10 12:45 PM, Luke Shepard wrote:
, at 8:41 AM, Dick Hardt wrote:
>
> > There is more to the web than the social web Luke, and supporting
> multiple AS has been a design goal of WRAP and OAuth 2.0 and is being
> implemented.
>
> Whoa, I didn't say there wasn't. I agree that supporting multiple
> auth
+1
On Fri, Jun 4, 2010 at 12:36 AM, wrote:
> +1
>
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Nat Sakimura
> Sent: Saturday, May 08, 2010 6:45 AM
> To: oauth
> Subject: [OAUTH-WG] "3.4. Client Credentials" text change proposal
>
> 3.
On 2010-06-04, at 6:39 PM, Luke Shepard wrote:
> I don't see how the extra parameter is required to support multiple auth
> servers for a resource.
it is needed if there are multiple token types
>
> Responses to Dick and Torsten:
>
> On Jun 4, 2010, at 11:33 AM, Dic
because we use it
On 2010-06-04, at 6:40 PM, Luke Shepard wrote:
> Why?
>
> On Jun 4, 2010, at 4:41 PM, Patrick Harding wrote:
>
>> +1
>>
>> Sent from my iPhone
>>
>> On Jun 4, 2010, at 5:38 PM, Brian Campbell
>> wrote:
>>
>>> On Thu, Jun 3, 2010 at 9:20 AM, Peter Saint-Andre
>>> wrote
;
> /thomas/
>
> __
>
>> -Original Message-
>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
>> Dick Hardt
>> Sent: Friday, June 04, 2010 9:59 PM
>> To: Luke Shepard
>> Cc: oauth@ietf.org
>> Subject: Re: [OAUT
off again.
>
> /thomas/
>
> __
>
>
>> -----Original Message-
>> From: Dick Hardt [mailto:dick.ha...@gmail.com]
>> Sent: Sunday, June 06, 2010 8:10 PM
>> To: Thomas Hardjono
>> Cc: oauth@ietf.org
>> Subject:
Background: The username / password flow can be used to brute force attack a
system to find valid credentials. A captcha is presented to slow the attack
down -- similar to what happens when you log in with an invalid password on a
webpage.
The captcha would be displayed by the app for the user
You are pointing out Marius point -- he wants to require registration. If the
redirect_uri is not registered, the only party that can detect that it is the
right URI is the user. The AS can only show the user the redirect_uri passed
over.
-- Dick
On 2010-06-07, at 5:31 PM, Chuck Mortimore wrot
On 2010-06-07, at 1:24 PM, Thomas Hardjono wrote:
> What if the username/password (or PIN) was used to release a secret (located
> in an OTP dongle) or to exercise a secret key (symmetric or asymmetric)
> located in a smartcard or TPM chip?
>
> Reading Section 3.8, it seems it covers these ca
+1
On 2010-06-10, at 1:29 PM, Eran Hammer-Lahav wrote:
> After taking a break from our previous debate(s) on the issue of which
> response format to support, I would like to suggest the following:
>
> - Support a single response format (including in the user-agent fragment)
> using JSON.
>
>
On 2010-06-13, at 11:20 AM, Evan Gilbert wrote:
>
>
> On Sun, Jun 13, 2010 at 8:18 AM, Eran Hammer-Lahav
> wrote:
> Using JSON in the end-user authorization endpoint response is still something
> we need to discuss. In the web server flow, it makes more sense to use
> form-encoded because t
+1 (JSON in direct response, separate discussion on redirect response)
On Mon, Jun 14, 2010 at 10:15 AM, Brian Eaton wrote:
> On Mon, Jun 14, 2010 at 10:00 AM, Eran Hammer-Lahav
> wrote:
> > So far we have 16 people supporting using JSON as the only response
> format
> > for the token endpoint
On 2010-06-14, at 9:41 PM, Evan Gilbert wrote:
>
> If a response from the AS is untrusted, there are much bigger issues at
> stake. ... or am I missing an obvious attack where random JSON would get sent
> to the Client?
>
> For the web server flow, you know the AS server you called and can re
+1
On 2010-06-14, at 9:02 PM, Brian Eaton wrote:
> On Mon, Jun 14, 2010 at 8:31 PM, Andrew Arnott wrote:
>> For an application I'm building, the installed client app will have
>> intermittent windows of time where it can obtain a (non-OAuth) assertion for
>> user identity. During this time, it
u have to say, but I'll defend to the death
> your right to say it." - S. G. Tallentyre
>
>
> On Mon, Jun 14, 2010 at 11:00 PM, Dick Hardt wrote:
> +1
>
> On 2010-06-14, at 9:02 PM, Brian Eaton wrote:
>
> > On Mon, Jun 14, 2010 at 8:31 PM, Andrew Arnott
Are you envisioning the client makes a call to AD to get an assertion where the
call is automagically authenticated as the user by NTLM?
What do you envision being the relationship between the AS and AD? What
authority does the AS have? How long is the refresh token valid for?
I think you have
Good point that version checking be clearly included in the spec.
On 2010-06-21, at 4:54 AM, Rob Richards wrote:
> I still think that the issue of running both 1.0 and 2.0 on an resource
> endpoint needs to be addressed in the spec. It is unrealistic to think that a
> provider currently running
Thanks for writing this up Dirk.
I would suggest that the token be:
payload "." envelope "." signature
This enables the payload to be encrypted and independent from the envelope.
Token signing, verification, encryption and decryption code can then be generic
and not understand the pay
-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
> Brian Eaton
> Sent: Monday, June 21, 2010 9:49 AM
> To: Dick Hardt
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] proposal for signatures
>
> On Mon, Jun 21, 2010 at 7:43 AM, Dick Hardt wrote:
> > Thanks for writin
On 2010-06-21, 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?
it is the ID of the key, not the client -- used to rollover keys
> Does "websafe-base64-encoded"
n...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
> Brian Eaton
> Sent: Tuesday, June 22, 2010 9:43 AM
> To: Dick Hardt; hannes.tschofe...@gmx.net
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] proposal for signatures
>
> On Tue, Jun 22, 2010 at 7:17 AM, Dick Hardt wrot
ue of key_id be?
>
> Thanks,
> --David
>
>
> On Tue, Jun 22, 2010 at 12:14 PM, Dick Hardt wrote:
> > I could imagine an architecture striving to be efficient, scalable,
> > distributed and secure where there are hundreds of servers each with a
> > unique private
One of the modifications I concluded to do to WRAP was to add in the type
parameter. I was happy to see if in David's draft.
Even though redundant in some ways, it make it very clear to both the client
and server what is intended.
+1 for putting it back in.
On Mon, Jun 14, 2010 at 11:23 AM, Bria
Per an earlier comment, "type" might not be the best name for the parameter.
Perhaps "method" might work and adds a clear extension point for other types
of calls?
On Tue, Jun 22, 2010 at 1:22 PM, Dick Hardt wrote:
> One of the modifications I concluded to do to WRAP
Core spec until signatures were extracted – then having a
>> key id is not needed. I certainly understand what they're used for,
>> but don't find them relevant as part of the OAuth conversation today.
>>
>> And yes, Applied Cryptography is worth reading
On 2010-06-22, at 11:07 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
> "
> scope
> OPTIONAL. The scope of the access request expressed as a list
> of space-delimited strings. The value of the "scope" parameter
> is defined by the authorization server. If the value c
iginal Message-
>> From: ext Lukas Rosenstock [mailto:l...@lukasrosenstock.net]
>> Sent: Thursday, June 24, 2010 10:49 AM
>> To: Dick Hardt
>> Cc: Tschofenig, Hannes (NSN - FI/Espoo); OAuth WG
>> Subject: Re: [OAUTH-WG] Scope :: Was: Extensibility for OAuth?
>>
hat are
> not allowed to be used in other cases, such as "std:".
>
> Ciao
> Hannes
>
>
>> -Original Message-----
>> From: ext William Mills [mailto:wmi...@yahoo-inc.com]
>> Sent: Thursday, June 24, 2010 8:15 PM
>> To: Tschofenig, Hannes
t;> there would still be the need to decide about the structure of the values
>> now. One possibility is to just add a prefix for standardized values that
>> are not allowed to be used in other cases, such as "std:".
>>
>> Ciao
>> Hannes
>>
>>
Would you elaborate on your reasons here? Do you think we have enumerated all
the possibilities?
On 2010-06-25, at 10:59 AM, Eran Hammer-Lahav wrote:
> I would rather limit the ability to extend the two endpoints beyond their
> current architecture, and instead, allow others to specify new end
> be extended a lot more than other extension types and would like to keep the
> process as light as possible (i.e. no registration at all).
>
> EHL
>
>> -Original Message-
>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
>> Of Di
s a bad thing. But adding a new parameter (such as language) is
> a good thing to support, and by requiring review, only parameters that don't
> change the overall design will be approved.
>
> EHL
>
>> -Original Message-
>> From: Dick Hardt [mailto:di
The RFC term is base64url which turns up much better results when searching.
"URL safe base64" is also a good search term.
Note that the token may also be included in the HTTP header. base64url encoding
works well for HTTP headers. Note that the token is opaque to the client, so
being plain tex
I vote for (3) unless a good (4) is suggested.
On 2010-06-27, at 6:51 PM, Eran Hammer-Lahav wrote:
> Over the past year many people expressed concerns about the use of the
> ‘realm’ WWW-Authenticate header parameter. The parameter is defined in RFC
> 2617 as required, and is allowed to have sch
The current spec defines scope (when the scope variable is introduced) as:
scope
OPTIONAL. The scope of the access request expressed as a list
of space-delimited strings. The value of the "scope" parameter
is defined by the authorization server. If the value contai
While the AS implementor can infer the request by the parameters, I prefer the
programmer explicitly state what she is doing. Thinking of it as a method
parameter rather than a type parameter makes more sense to me. Similiarly, HTTP
has GET, POST, PUT etc. even though you could differentiate bet
PM, Eran Hammer-Lahav wrote:
>
>> I don’t care about the name (type vs method). Are there any objection to
>> defining a parameter for the client authentication method? Any views about
>> using this parameter with an HTTP authorization header?
>>
>> EHL
>>
&
On 2010-07-01, at 12:52 PM, Naitik Shah wrote:
> Searching for base64url does make it better. Thanks for that pointer Dick.
>
> We don't think base64url will work, because the most common error we'll see
> is that developers forget the "url" part and just do plain base64, and that's
> not suff
On 2010-07-02, at 5:04 PM, Paul Tarjan wrote:
>>> We don't think base64url will work, because the most common error we'll see
>>> is that developers forget the "url" part and just do plain base64, and
>>> that's not sufficient because the stock set includes +.
>>
>> I think forgetting to url-d
On 2010-07-03, at 9:13 AM, Naitik Shah wrote:
> > I think Naitik is saying that accidentally doing base64 and not base64url
> > will send some '+'s along.
>
> if there are '+'s in the token, then it is easy for someone helping to spot
> the problem. also easy for servers to send back an error m
On 2010-07-03, at 11:28 AM, Luke Shepard wrote:
>>
>>> >
>>> > * We'd like the signature first (so you can left split instead of right
>>> > split)
>>>
>>> What are the advantages of left split vs right split?
>>>
>>> Built in split function with a limit is more common, which makes the left
On 2010-07-03, at 12:14 PM, Naitik Shah wrote:
> On Sat, Jul 3, 2010 at 9:42 AM, Dick Hardt wrote:
>
> On 2010-07-03, at 9:13 AM, Naitik Shah wrote:
>> > I think Naitik is saying that accidentally doing base64 and not base64url
>> > will send some '+'s a
hash, and not all browsers decode the hash the same way.
>
> Also being able to copy a value from a URL and use it directly in a tool or
> Authorization header is invaluable for debugging.
>
> Per notes above, the transformation is very straightforward.
>
> Evan
>
> On
D
On 2010-07-08, 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) Maybe, depends on some other reason
/30/837.aspx.
>
>
> So I would suggest that encrypted payloads are implemented as an encryption
> of a JSON Token, as in:
>
> encrypted_token = encryption(JSON_Token) || "." || envelope
> envelope = base64(JSON(everything you need to know to decrypt))
>
>
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 (semantic web stuff). I've written a few OAuth applications
I agree we don't want to end up like other protocols that were too generic. :)
The use case I am arguing for is sending encrypted tokens. Higher levels of
assurance require this and various people brought this up as a requirement when
WRAP was presented at IIW 09B.
-- Dick
On 2010-07-10, at 11
On 2010-07-10, at 1:21 PM, David Recordon wrote:
> 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 t
On 2010-07-10, at 1:42 PM, David Recordon wrote:
> 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
>>
header and body in HTTP requests. A
separation of transport parameters from payload data has proven useful in many
other architectures and protocols.
-- Dick
>
> Dirk.
>
> On Fri, Jul 9, 2010 at 4:45 PM, Dick Hardt wrote:
> Hi Dirk
>
> Responding to this now that you are
On 2010-07-15, at 6:45 PM, Naitik Shah wrote:
> On Thu, Jul 15, 2010 at 5:43 PM, Dirk Balfanz wrote:
>
> One question: What's the deal with having the signature go first? If you can
> explain to me why that is a good idea, I'm happy to oblige.
>
>
> When we were talking about base64url or no
On 2010-07-17, at 12:51 PM, Eran Hammer-Lahav wrote:
> client_credentials worked fine before. I'll just replace none with that. No
> one had an issue with the name in -05.
+1
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinf
Thanks for sharing Paul!
On 2010-07-26, at 3:18 PM, Paul Tarjan wrote:
> Facebook released an early version of the proposed signature method, with the
> aim of getting real-life implementation experience. We are not currently
> using this for protected resource requests, but rather more like if
On 2010-07-27, at 12:34 AM, Nat Sakimura wrote:
> I have a fundamental question.
>
> While separating signature and payload by a dot "." seems ok,
> I still have not the answer for the question "why not make everything
> into JSON and base64url it?".
bloat from base64 encoding twice
>
> BTW,
I agree with your point that consensus is based on individual voices.
I agree with Eric's points that signatures are a generic security mechanism and
that signatures should be in a separate spec.
-- Dick
On 2010-09-23, at 6:11 PM, Eran Hammer-Lahav wrote:
> It is pretty clear from the recent
That's a confusing answer Eve. Is it in the spec or pointed to from the spec?
I think there is consensus that there are enough use cases that signatures need
to be spec'ed -- the question is if the signature spec is in core or a separate
spec.
For people that don't need signatures, having them
-1 in core
+1 to being referenced in core and being a separate document
On 2010-09-23, 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
ple as possible. Seems like those
> opposed signatures got everything they want, don’t really care about others,
> and are ready to call it a day.
>
> EHL
>
>
> On 9/24/10 5:20 PM, "Dick Hardt" wrote:
>
> That's a confusing answer Eve. Is it in the s
ll be breaking the spec into more than two
> parts. Basically, I will be creating a version that does not force anyone to
> read anything they might not care about. Clearly, we shouldn’t based
> editorial decisions on what you want to read :-)
>
> EHL
>
>
> On 9/24/1
s completely subjective to how important one think
> it is.
>
> EHL
>
>
> On 9/24/10 10:43 PM, "Dick Hardt" wrote:
>
> I don't follow your logic ... or perhaps I don't see why the spec needs to be
> written in more than two parts.
>
>
On 2010-09-25, at 7:52 PM, Eve Maler wrote:
> It seems like you figured it out pretty quickly, given the message you sent
> immediately after. :-)
>
> Referencing another spec from the core spec using normative text is
> effectively "including it by reference". I meant that I'm sympathetic (+
Did you intentionally decide not to support encrypting the token?
On 2010-09-23, at 5:22 PM, Mike Jones wrote:
> Recognizing that there is substantial interest in representing sets of claims
> in JSON tokens, Yaron Goland and I have put together a draft JSON Web Token
> (JWT) spec for that purp
wrote:
> I’d be open to a proposal for also supporting encryption. The draft was
> intended to be a starting point for productive discussion – not a finished
> product.
>
> Your thoughts?
>
> -- Mike
>
>
On 2010-09-26, at 11:02 PM, Eran Hammer-Lahav wrote:
> Clearly, this group is making choices based on the kind of applications using
> OAuth 1.0 today. The decision to focus on bearer tokens came from specific
> experiences and types of consumer web services.
Any other applications are hypothe
37 PM, Eran Hammer-Lahav
> wrote:
>
>
> > -Original Message-
> > From: Dick Hardt [mailto:dick.ha...@gmail.com]
> > Sent: Sunday, September 26, 2010 11:21 PM
>
> > > What I absolutely object to is presenting a specification that to a new
> >
As others have stated and I agree with, you also need an extension mechanism so
that other signature algorithms can be used. If there is no extension
mechanism, then the spec is saying this is the only signature mechanism
possible.
-- Dick
On 2010-09-26, at 11:44 PM, Eran Hammer-Lahav wrote:
is 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 Hardt wrote:
> Don't put the signature information in the token, put it in a sepa
On 2010-09-27, at 8:14 AM, Eran Hammer-Lahav wrote:
> That goes without saying.
No it does not. We are talking about normative specifications.
> Yes. Does this satisfy your concerns?
Depends on the quality of the extension mechanism.
Many of the people wanting signing want something stronger
ithm included.
See my other message.
>
> We need to find a way to give each side something to live with.
>
> EHL
>
>
> From: Dick Hardt [mailto:dick.ha...@gmail.com]
> Sent: Monday, September 27, 2010 6:31 AM
> To: John Panzer; Eran Hammer-Lahav
> Cc: OAuth
Myself and others feel that a spec for how to sign a request would be useful
for other specifications. As I noted in a previous email, there was dismay when
the signing of an OpenID message was very similar, but different than the
signing in OAuth 1.0A.
Signing messages was a huge stumbling bl
On 2010-09-27, at 11:25 AM, Torsten Lodderstedt wrote:
> Am 27.09.2010 19:11, schrieb Anthony Nadalin:
>> What is needed is needed is the security considerations section complete, I
>> don't think that the signature specification has to be in the core to be
>> complete, there are previsions to
I am mildly concerned that breaking the spec into multiple parts makes it
harder for the spec reader to understand what is going on. Where does a
complete example of getting and using a token? Imagine how confusing HTTP would
be if the request and response were in separate specs.
I'm not sure t
Note there will be three documents not two.
The suggested change does not address the issue that myself and others had
raised with having signatures be in the core. The suggestion was that having
signatures be a different spec made them reusable by other groups and enabled a
more comprehensive
On 2010-09-30, at 11:33 AM, Eran Hammer-Lahav wrote:
>> -Original Message-
>> From: Dick Hardt [mailto:dick.ha...@gmail.com]
>> Sent: Thursday, September 30, 2010 7:45 AM
>
>> The suggested change does not address the issue that myself and others had
>>
On 2010-10-26, at 4:33 PM, Mike Jones wrote:
> Having a simple discovery method for services and resources is key to
> enabling many Internet scenarios that require interactions among parties that
> do not have pre-established relationships. For instance, if Joe, with e-mail
> address j...@ex
On 2011-01-05, at 7:01 PM, Francisco Corella wrote:
> --- On Wed, 1/5/11, Marius Scurtescu wrote:
> > > This seems to be saying that the user's machine has a Web
> > > server running on it which is reachable from the Internet by
> > > sending an http request to the redirection URI. That's
> > >
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 s
have the JWT process in your docs, it's easy enough. We're not worried about
> this odd phase of early adoption with no standard library."
>
> -jeff
>
> On Fri, Jan 7, 2011 at 10:42 AM, Dick Hardt wrote:
> Hi Jeff
>
> Thanks for the feedback. A healthy deba
On 2011-01-10, at 3:25 PM, Brian Eaton wrote:
> On Mon, Jan 10, 2011 at 3:06 PM, Eran Hammer-Lahav
> wrote:
>> What about the difference between the two access tokens? The one issued
>> directly and the one via the code? Are those the same? Same scope? Same
>> duration?
>
> Same.
>
>> I thi
+1 for flow based option (#2) -- it prioritizes the security implications, and
then readability for a much larger audience (client developer)
On 2011-01-11, at 11:19 PM, Eran Hammer-Lahav wrote:
> (Vote at the end, please read)
>
> Background
>
> Between draft -00 and -05 the document used a
401 - 500 of 540 matches
Mail list logo
