gt; Sent: Wednesday, March 24, 2010 10:25 AM
>> To: Dick Hardt
>> Cc: OAuth WG
>> Subject: Re: [OAUTH-WG] new sponsorship, time available for WG
>>
>> On Tue, Mar 23, 2010 at 10:18 PM, Dick Hardt wrote:
>>> Microsoft recently offered to sponsor me to work on
On 2010-03-25, at 9:55 AM, Brian Eaton wrote:
> On Thu, Mar 25, 2010 at 6:09 AM, Subbu Allamaraju wrote:
>> Just curious - why can't the client check the Date header?
>
> Yes, that works, but lots of clients don't realize it is possible.
Do all clients have access to it?
_
my bad, Marius is correct
On 2010-03-30, at 12:07 PM, Marius Scurtescu wrote:
> This must be an editing error.
>
> Version 0.9.7.2 of the spec requires exactly the other way around, the
> correct way: Client Account and Password (5.1) does not return a
> refresh token, and Username and Password
There are times when a resource may have different scope for different kinds of
access. realm != scope
On 2010-04-02, at 2:45 PM, Igor Faynberg wrote:
>
>
> I don't see any problem at all.
>
> Igor
>
> David Recordon wrote:
>> Assuming that this is mean to replace the scope parameter?
>>
>>
On 2010-04-06, at 12:16 AM, Eran Hammer-Lahav wrote:
>
>
>
> On 4/2/10 3:27 PM, "Dick Hardt" wrote:
>
>> There are times when a resource may have different scope for different kinds
>> of access. realm != scope
>
> No. Realm is a subset. It is
On 2010-04-07, at 4:26 PM, Eran Hammer-Lahav wrote:
> Latest is always at:
>
> http://github.com/theRazorBlade/draft-ietf-oauth
>
> (xml is always up to date. txt and html when I can. Atom feed available)
>
> ---
>
> I finished going over sections 1-4 which includes the overview, flows, and
>
Eran
Richard and Lief are describing the same point we had in the past where Peter
surmised the discussion that an *implementation* MUST support TLS is required
for bearer tokens to be compliant, and that TLS is recommended for *deployment*
-- Dick
On 2010-04-07, at 4:21 PM, Eran Hammer-Lahav
I would envision that the requests from different flows will have a different
mode value, which makes them uniquely different requests for the AS.
I think returning a refresh token when it can't be used will lead to confusion
for Client and AS developers.
-- Dick
On 2010-04-07, at 1:51 PM, Era
(restarting discussion from
http://groups.google.com/group/oauth-ietf-wg/browse_thread/thread/8aeb31817ead4c2a/f19773643e0a8ba3?pli=1
with matching subject)
Given the practice that the authorization endpoint and the redirect_uri can
contain URI query parameters, then differentiating bet
The scope parameter was included in WRAP at the request of library and AS
implementors to standardize a commonly included parameters.
The client_id parameter seems similar to the scope parameter. The meaning of
client_id is not defined in the spec and is AS specific. A client_id that a
developer u
; I think we need to add a bit more definition to the scope parameter.
> Maybe as simple as a comma-separated list of strings.
>
>
> On Sun, Apr 18, 2010 at 6:12 PM, Dick Hardt wrote:
>> The scope parameter was included in WRAP at the request of library and AS
>> implementor
re quite dubios of no oauth_
> prefix after hacking on a draft implementation their opinion has
> changed. They're now really enjoying shorter and cleaner paramater
> names and found them to be easier to document and no more difficult to
> implement.
>
>
> On Sun, Apr 18,
The spec describes the access token as an identifier. One of the key
capabilities of WRAP was that the token could be self contained. The PR could
make an access control decision by examining the access token and not calling
the AS.
The token is referred to as an identifier in the Abstract, In
General comments:
Putting the flow description, diagram and steps in the section with the spec
work well.
Use of "server" term. In numerous places, the term server is used instead of
authorization server or resource server (maybe even web server). To avoid
ambiguity, I would suggest the term s
On 2010-04-18, at 9:04 PM, Marius Scurtescu wrote:
> On Sun, Apr 18, 2010 at 5:46 PM, Dick Hardt wrote:
>> Since calls to the token endpoint use POST, there can not be any confusion
>> between the parameters in the body of the message and URI query parameters
>
> Unfo
Why was the state parameter removed from the web server flow?
Some AS may require the entire redirect URI to be registered, so the state
parameter allows a client to maintain state across calls.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org
Some AS will match part of the URI to what was registered, some require
everything up to the start of a query. The spec needs to clarify how much of
the URI needs to be matched, or state it is AS specified.
-- Dick
___
OAuth mailing list
OAuth@ietf.org
The AS token endpoint response is encoded as application/x-www-form-urlencoded
While this reuses a well known and understood encoding standard, it is uncommon
for a client to receive a message encoded like this. Most server responses are
encoded as XML or JSON. Libraries are NOT reedily availabl
I recall some earlier discussion on calling the scheme Token vs OAuth and see
that it is now Token per the example:
Authorization: Token token="vF9dft4qmT"
Would explain or point out the logic of using Token rather than OAuth?
A related question: is the scheme case sensitive?__
+1 to #1
On 2010-04-18, at 9:35 PM, Luke Shepard wrote:
>
> 1/ We leave the scope parameter as an Auth Server-specific, opaque parameter.
> 2/ We all agree on a format and spec for the scope parameter.
> 3/ We drop the scope parameter and make each server define their own,
> non-standard scope pa
On 2010-04-18, at 9:56 PM, Eran Hammer-Lahav wrote:
> The client_id parameter is not expected to have an internal structure known
> to clients.
The client developer needs to understand it.
> The likelihood of a client library treating this value as anything other than
> an opaque string is p
n open redirector. On the other hand, limiting the sub-domain
> can make scalability harder.
>
> Care to propose text?
>
> EHL
>
>> -Original Message-
>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
>> Of Dick Hardt
>>
On 2010-04-18, at 10:28 PM, Eran Hammer-Lahav wrote:
>
>
>> -Original Message-
>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
>> Of Dick Hardt
>> Sent: Sunday, April 18, 2010 9:20 PM
>> To: OAuth WG
>> Subject:
On 2010-04-19, at 9:25 AM, Eran Hammer-Lahav wrote:
> 2. Server requires authentication
>
>HTTP/1.1 401 Unauthorized
>WWW-Authenticate: Token realm='Example', scope='x2'
Can more than one scope be returned? Is it a comma delimited list?
I wonder how much value this will provide. (I like
8:30am might be a tad early ...
On Mon, Apr 19, 2010 at 2:23 PM, IESG Secretary wrote:
> Location:
>
> This interim meeting is attached to the Internet Identity Workshop
> (see http://www.internetidentityworkshop.com/) in Mountain View, CA.
>
> Time:
>
> 20th of May, 8:30am - 6pm
>
> Meeting Host
On Mon, Apr 19, 2010 at 8:03 PM, Marius Scurtescu wrote:
> Hi Eran,
>
> The spec looks really good, thanks for all the work you put into it.
>
> I think it was a good idea to remove the 401 responses and use only 400.
>
>
In WRAP we had used 401s when the client credentials were invalid and 400
wh
On 2010-04-19, at 9:46 PM, Peter Saint-Andre wrote:
> On 4/18/10 6:46 PM, Dick Hardt wrote:
>
>> Given the practice that the authorization endpoint and the redirect_uri
>> can contain URI query parameters, then differentiating between
>> application specific query param
+1 as starting point. :)
On Tue, Apr 27, 2010 at 11:55 AM, Peter Saint-Andre wrote:
> On 4/26/10 3:14 PM, Marius Scurtescu wrote:
> > +1
> >
> > I am assuming this means that the current draft will become the
> > initial check point, version 00. Is that correct?
>
> Correct.
>
> /psa
>
>
> __
On 2010-04-30, at 9:02 AM, Yaron Goland wrote:
> I actually have a preference for application/x-www-form-urlencoded but it's
> not overwhelming, the key thing I believe we need to do is have exactly one
> request/response format. In other words, I don't believe we should use one
> format for r
>>>
>>>> There seems to be support for this idea with some concerns about
>>>> complexity. Someone needs to propose text for this including defining the
>>>> request parameter and schema of the various reply formats.
>>>>
>>&g
On 2010-04-20, at 2:31 PM, Eran Hammer-Lahav wrote:
> All the issues around encoding in 1.0 were about signatures. This is no
> longer an issue.
Don't we still support signatures? I still see if in the spec. :)
-- Dick
___
OAuth mailing list
OAuth@
ems to be support for this idea with some concerns about complexity.
> Someone needs to propose text for this including defining the request
> parameter and schema of the various reply formats.
>
> EHL
>
> > -Original Message-----
> > From: Torsten Lodderste
On 2010-05-01, at 3:48 PM, Luke Shepard wrote:
> I agree with approach #3.
>
> As for the delimiter, I'm fine if the spec wants to do space-delimited.
>
> Just FYI Facebook will also continue to support and document commas in
> addition to whatever the spec says, because spaces are typically
On 2010-05-09, at 2:06 PM, Eran Hammer-Lahav wrote:
> DEADLINE: 5/13
>
> I would like to publish one more draft before our interim meeting in two
> weeks (5/20). Below are two open issues we have on the list. Please reply
> with your preference (or additional solutions) to each item. Issues wi
On 2010-05-09, at 3:25 PM, Eran Hammer-Lahav wrote:
>
>> 3.2.1.1. Access Token Response
>>expires_in
>> OPTIONAL. The duration in seconds of the access token
>> lifetime.
>>
>>refresh_token
>> OPTIONAL. The refresh token used to obtain new access tokens
>>
I prefer authorization endpoint as it talks about the functionality of what the
client gets from that endpoint. Delegation endpoint is another alternative.
User endpoint implies there must be a user present. I envision scenarios where
an identity agent deals with the authorization for the user a
There has been some discussion about modifying the scope of the access token
during a refresh. Perhaps we can add another "method" to what the AS MAY
support that allows modifying the scope of an access token. Type of request is
"modify" and the scope parameter is required to indicate the new sc
Twitter has an interesting use case that may become common: one client needs to
delegate access to another client. Similar to the 'modify' method where the
scope of the access token can be modified, the 'delegate' method allows a
client to request delegation to another client (the delegate). Her
>>>
>>> Right now it depends on the server.
>>
>> The spec should clarify that. Suggested wording:
>>
>>
>> If the client has previously registered a redirection URI with the
>> authorization
>> server, the authorization server MUST verify that the redirection URI
>> received matches the regi
On 2010-05-10, at 1:11 AM, Pid wrote:
> On 10/05/2010 07:57, Joseph Smarr wrote:
>>> 1. Server Response Format
>>
>> I vote for B, though I could live with C. (A would make me sad though)
>>
>> We've had a healthy and reasonable debate about the trade-offs here, but
>> I think the main countera
On 2010-05-10, at 4:20 PM, Brian Eaton wrote:
> On Sun, May 9, 2010 at 7:34 PM, Dick Hardt wrote:
>> There a couple of choices for the flows for how a successful delegation is
>> conveyed to the delegate. The AS could return a delegation code that is
>> similar to a veri
n.
>
> EHL
>
>> -Original Message-
>> From: Marius Scurtescu [mailto:mscurte...@google.com]
>> Sent: Monday, May 10, 2010 12:49 PM
>> To: Eran Hammer-Lahav
>> Cc: Dick Hardt; OAuth WG (oauth@ietf.org)
>> Subject: Re: [OAUTH-WG] modifying the scope o
for this? Either way sounds like it belongs
>> in an extension.
>> >>
>> >> EHL
>> >>
>> >>> -Original Message-
>> >>> From: Marius Scurtescu [mailto:mscurte...@google.com]
>> >>> Sent: Monday, May 10, 2010 12:49 PM
>>> -Original Message-
> >>> From: Marius Scurtescu [mailto:mscurte...@google.com]
> >>> Sent: Monday, May 10, 2010 12:49 PM
> >>> To: Eran Hammer-Lahav
> >>> Cc: Dick Hardt; OAuth WG (oauth@ietf.org)
> >>> Subject: Re:
On Tue, May 11, 2010 at 11:31 PM, Luke Shepard wrote:
> FWIW, Facebook does not do strict equality matching on redirect_uri. We
> accept any redirect_uri that has either:
>
> - its prefix is the registered url
> - or it is a special facebook.com/xd_proxy.php url, with an origin
> parameter that ha
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.
Torsten: enabling a client to revoke a refresh token looks like a useful
mechanism. I anticipate it will be v
Not sure if you intended this, but you are mixing user present and user not
present access control.
I do NOT think we want OAuth protected images to be the same as Basic auth
protected images. I do think OpenID protected images and Basic auth are
similar. With OAuth today, the user has granted exp
Note that you could accomplish this functionality with the 'modify' proposal
I posted where an access token with a different scope could be requested
could be used to acquire a second token that has less privileges and would
be appropriate over HTTP.
To recap, 'modify' is like 'refresh' except the
Looking over the previous threads, I don't think an important capability was
pointed out that we want to preserve:
The AS may NOT need or want to know where an access token is used. In other
words, the access token could be viewed as a claim that can presented to an
arbitrary resource to gain acce
Below is proposed text where a token is referred to as an identifier.
Here is the definition of identifier from RFC 4949:
$ identifier
(I) A data object -- often, a printable, non-blank character
string -- that definitively represents a specific identity of a
system entity,
On 2010-05-16, at 3:46 PM, oauth issue tracker wrote:
> #6: Make automated self-registration of unique clients possible
> -+--
> Reporter: e...@…| Owner:
> Type: enhancement | Status: n
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
>>
>>
301 - 400 of 523 matches
Mail list logo
