and preserves the behavior of requests following the rules of section
5.1.1..
regards,
Torsten.
Paul
On Aug 16, 2010, at 3:09 PM, Torsten Lodderstedt wrote:
I would like to furthermore track down the relevant use cases. Assuming you are
referring to section 5.2.1, how does your client send
17.08.2010 00:51, schrieb Lukas Rosenstock:
+1 for your option 1a or 1b
- 1c introduces another token to manage with the id, which I feel
should be avoided.
- 2 would also be fine, though not so beautiful in terms of
architecture.
2010/8/16 Torsten Lodderstedt tors...@lodderstedt.net
mailto:tors
Hi all,
I intend to submit a I-D for token revocation. Based on previous
discussions on the mailing list and here at Deutsche Telekom, I see a
couple of design options. I would like to share those options with the
WG and try to reach consensus on a single option before investing the
time to
I would like to furthermore track down the relevant use cases. Assuming
you are referring to section 5.2.1, how does your client send the access
token to the resource server? I'm asking because I think error handling
for URI query parameters, Body parameters and Authorization headers
could be
multiple (SAML) assertions also mean multiple subject statements. Are there any
constraints regarding the relations among those subjects (identities)?
regards,
Torsten.
Am 12.08.2010 um 22:01 schrieb Brian Campbell bcampb...@pingidentity.com:
I generally agree more with Chuck, David and
Eve,
thank you for writting this document. I consider it a good starting point for a
discussion about client registration and discovery. Will you propose this as a
WG item?
My comments questions:
You propose a host-meta based discovery of the registration endpoint on the
authz server. Could
Am 11.08.2010 um 12:40 schrieb Torsten Lodderstedt tors...@lodderstedt.net:
Eve,
thank you for writting this document. I consider it a good starting point for
a discussion about client registration and discovery. Will you propose this
as a WG item?
My comments questions:
You
Am 11.08.2010 um 17:40 schrieb Christian Scholz c...@comlounge.net:
Am 11.08.10 17:31, schrieb Torsten Lodderstedt:
How is a UMA requestor envisioned to discover the auth server?
On the Host side the user can tell it which AM (in UMA terms it's an
Authorization Manager, some
?
regards,
Torsten.
Am 10.08.2010 um 19:57 schrieb Torsten Lodderstedt tors...@lodderstedt.net:
Thank you for the explanation.
I now understand that the fragment is used for efficiently passing token or
code on the client side. What I still don't understand is why a client would
need both
of doing that, because that relay.html page
is static and can be cached by a browser.
None of the answers above looks very convincing to me, but that's where UA
is now.
From: Torsten Lodderstedt tors...@lodderstedt.net
Can someone pls. explain why code and token should both be returned
do a terrible good job as an
editor. I just offered my opinion of why this WG is not as focused as you would
expect it.
regards,
Torsten.
EHL
-Original Message-
From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Wednesday, August 04, 2010 10:05 AM
To: Eran Hammer
at 10:04 AM, Torsten Lodderstedt
tors...@lodderstedt.net wrote:
So far no one has offered to work on the security consideration section
(Brian's draft is too far from the format I need to incorporate).
I could work on this topic, if Brian does not insist to do so.
@Brian: What do you think
In my opinion, this decision is up to the authorization server and not
the resource server. Or should both be possible? What do you think?
Theoretically, the decision should probably be up to the authorization server.
In practise, however, the decision should be *delivered* from the
enpoints allows a simple way to
minimize on one path.
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org]
On Behalf Of Manger, James H
Sent: Tuesday, August 03, 2010 8:01 PM
To: Torsten Lodderstedt
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth
02.08.2010 um 22:20 schrieb Torsten Lodderstedt tors...@lodderstedt.net:
In the WG meeting at Maastricht, I have been asked to write down my
requirements regarding Discovery. And here they are:
Assumptions: Discovery allows a compliant client to automatically obtain all
deployment specific data
+1
Brian's profile serves a distinct purpose. I don't see a problem with different
assertion profiles for using SAML with OAuth, especcially given the wide usage
of SAML.
Regards,
Torsten.
Am 04.08.2010 um 07:21 schrieb Eran Hammer-Lahav e...@hueniverse.com:
The single assertion use case
it gets added). I specifically want this for
SASL discovery.
-bill
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org]
On Behalf Of Torsten Lodderstedt
Sent: Wednesday, August 04, 2010 12:39 AM
To: Torsten Lodderstedt
Cc: OAuth WG (oauth@ietf.org)
Subject: Re
um 22:33 schrieb Eran Hammer-Lahav
e...@hueniverse.com:
General discussions on the list and during the interim meeting.
EHL
-Original Message-
From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Monday, August 02, 2010 1:20 PM
To: Eran Hammer-Lahav
Cc: OAuth WG (oauth
James,
This example illustrates that OAuth2 discovery needs to let a service
explicitly indicate whether a direct and/or user-delegation flow is required.
For instance, a WWW-Authenticate: OAuth2 response could define 2 parameters:
'user-uri' and 'token-uri'. If only one is present, only the
.
Am 02.08.2010 um 22:33 schrieb Eran Hammer-Lahav e...@hueniverse.com:
General discussions on the list and during the interim meeting.
EHL
-Original Message-
From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Monday, August 02, 2010 1:20 PM
To: Eran Hammer-Lahav
regards,
Torsten.
Am 02.08.2010 um 22:33 schrieb Eran Hammer-Lahav
e...@hueniverse.com:
General discussions on the list and during the interim meeting.
EHL
-Original Message-
From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Monday, August 02, 2010 1:20 PM
the existing authorization server endpoints (end-user authorization and
tokens endpoint) have a relatively clearly semantics and scope. Adding
distinct new functions to an authorization server will (in my opionion)
require the definition of new endpoints. For example, I'm working on an
I-D for
...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Torsten Lodderstedt
Sent: Monday, August 02, 2010 12:54 PM
To: OAuth WG (oauth@ietf.org)
Subject: [OAUTH-WG] Extensibility: new endpoints
the existing authorization server endpoints (end-user authorization and
tokens endpoint) have a relatively
In the WG meeting at Maastricht, I have been asked to write down my
requirements regarding Discovery. And here they are:
Assumptions: Discovery allows a compliant client to automatically obtain
all deployment specific data required to securely access a particular
resource servers as well as
for discovery/dynamic registration that meets our needs.
Hoping it can feed into Eran's discovery work.)
Eve
On 28 Jul 2010, at 1:23 AM, Torsten Lodderstedt wrote:
thanks for sharing your thoughts.
Differentiating resource servers by using different end-user
authorization endpoint URLs is an option
Darren,
I have got some questions regarding your posting, esp. the assertion.
1) cliqset.com would like to request an access token from google.com.
Sends a request with grant_type=assertion.
Request:
POST /token HTTP/1.1
Host: google.com
Content-Type: application/x-www-form-urlencoded
-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-00.html
On Thu, Jul 29, 2010 at 2:40 AM, Torsten Lodderstedt
tors...@lodderstedt.net wrote:
Darren,
I have got some questions regarding your posting, esp. the assertion.
1) cliqset.com would like to request an access token from google.com.
Sends
on the
provider. It is merely an assertion the UserA on HostX made the
request.
On Thu, Jul 29, 2010 at 1:05 PM, Torsten Lodderstedt
tors...@lodderstedt.net wrote:
So this assertion is conceptually equivalent to a case where the client
would have sent username and password of dbounds at the authz server
Am 28.07.2010 um 01:40 schrieb Brian Eaton bea...@google.com:
On Tue, Jul 27, 2010 at 11:56 AM, Brian Campbell
bcampb...@pingidentity.com wrote:
There seem to be two potential arguments against it - the burden of
tracking the state and the potential that it's unnecessarily
restrictive. I
it. - S. G. Tallentyre
On Thu, Jul 22, 2010 at 3:07 PM, Torsten Lodderstedt
tors...@lodderstedt.net mailto: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 at 10:03
I think the proposed parameters are useful for registered clients, too.
For installed applications, there is always the chance a user authorizes
the same application (==binary==client_id?) several times, every time on
a different device. It would be helpful to differentiate those copies.
If I understand your proposal correctly, you assume the clients knows
better than the authz server how to fit the client presentation
capabilities the best.
Wouldn't it be neccessary to also tell the authz server the screen
orientation and available size?
regards,
Torsten.
Am 12.07.2010
Am 15.07.2010 07:14, schrieb Brian Eaton:
...
My use cases for this are a little different.
1) I'm interested in the two-legged flows as well as three-legged flows.
For example, imagine an autonomous client that is registered once,
and then after that maintains its own key material.
Am 19.07.2010 06:34, schrieb Brian Campbell:
Torsten,
Thanks for taking the time to review and comment. I've tried to
address your questions inline below (though in some cases only raising
more questions).
On Sun, Jul 18, 2010 at 9:48 AM, Torsten Lodderstedt
tors...@lodderstedt.net wrote
On Sun, Jul 18, 2010 at 8:20 AM, Torsten Lodderstedt
tors...@lodderstedt.net mailto:tors...@lodderstedt.net wrote:
Hi Dirk,
I have some questions concerning your proposal:
- As far as I understand, the difference to magic signatures
lays in the usage of a JSON token carrying
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 at 10:03 AM, Torsten Lodderstedt
tors...@lodderstedt.net wrote:
As I have written in my reply to Marius's posting. I'm fine with
including
server ids in scopes
Hi Dirk,
I have some questions concerning your proposal:
- As far as I understand, the difference to magic signatures lays in
the usage of a JSON token carrying issuer, not_before, not_after and
audience. While such properties are important for security tokens
(assertions), I cannot see an
Hi Brian,
thank you for taking the effort to write this I-D.
I have the following remarks:
Why do you prescribe to include the token endpoint URL into the
SubjectConfirmationData and similar data also in the
AudienceRestriction? I would expect such data in the AudienceRestriction
only.
Am 16.07.2010 18:35, schrieb Brian Eaton:
On Fri, Jul 16, 2010 at 4:47 AM,wolfgang.steigerw...@telekom.de wrote:
+1 to Thorstens statement. There are use cases beyond local deployments.
Definitely.
For example, I'm interested in deployments where neither clients nor
resource
good idea.
Am 16.07.2010 21:26, schrieb Brian Eaton:
On Fri, Jul 16, 2010 at 12:22 PM, Brian Campbell
bcampb...@pingidentity.com wrote:
+1 for something different but not client password as sounds like it
would preclude other methods of client authentication
I think it would work
, Torsten Lodderstedt tors...@lodderstedt.net wrote:
Am 14.07.2010 23:52, schrieb Brian Eaton:
On Wed, Jul 14, 2010 at 2:48 PM, Torsten Lodderstedt
tors...@lodderstedt.net wrote:
Yepp. That's an optimization of use case 2. That way the authz server does
not need to store
Marius Scurtescu schrieb:
On Wed, Jul 14, 2010 at 3:22 PM, Torsten Lodderstedt
tors...@lodderstedt.net wrote:
I have a question concerning the OAuth philosophy: How many resource servers
may be managed by a single OAuth authorization server? (a) A single resource
server or (b) several
+1 for OAuth2
Brian Eaton schrieb:
Draft 10 switched from Token scheme in the authorization header to
OAuth. I'd rather we didn't reuse OAuth. 'OAuth2' would be great.
Token is ugly as sin, but is better than OAuth.
Spec section: http://tools.ietf.org/html/draft-ietf-oauth-v2-10#page-30
The
' and
'photos:server2' as scopes?
EHL
On 7/14/10 10:49 PM, Torsten Lodderstedt tors...@lodderstedt.net
wrote:
Did I get you right? Your answer is: Oauth is not suited for
deployments with different resource servers which rely in a single
authz server?
I don't know why you categorize
or requirement on the
maximum size of the code as well?
-Brian
On Thu, Jul 15, 2010 at 1:23 AM, Igor Faynberg
igor.faynb...@alcatel-lucent.com wrote:
An important point, which I think should be captured in the security
consideration section.
Igor
Torsten Lodderstedt wrote:
what about
Am 15.07.2010 20:14, schrieb Marius Scurtescu:
On Thu, Jul 15, 2010 at 10:03 AM, Torsten Lodderstedt
tors...@lodderstedt.net wrote:
As I have written in my reply to Marius's posting. I'm fine with including
server ids in scopes. But this requires a definition of the scope's syntax
where is the relation between token version and HTTP authentication
scheme version?
regards,
Torsten.
Am 15.07.2010 23:34, schrieb Naitik Shah:
I though we'd come to a decision on the versioning too :) IMHO, it's
better to push this burden of versioning into the token itself if
necessary. I
Am 15.07.2010 16:27, schrieb Christian Stübner:
Torsten,
I came across your I-D when looking for a way to distinguish between
different protected resources.
Just some remarks and questions:
o In 3.1. I suppose your example request is missing the service_id, right?
Yepp.
o 3.4. Replace
On Tue, Jul 13, 2010 at 9:58 PM, Torsten Lodderstedt
tors...@lodderstedt.net wrote:
We plan to issue new refresh tokens for certain clients only (mobile, desktop),
it's part of the client-related policy. So the behavior for a particular client
is predictable.
Nice.
Would you
On Wed, Jul 14, 2010 at 2:36 PM, Torsten Lodderstedt
tors...@lodderstedt.net wrote:
I would also like to see support for b. In this case, additional means for
client authentication should be considered.
b is token on query string?
What's the use case for that?
Yepp. That's
I have a question concerning the OAuth philosophy: How many resource
servers may be managed by a single OAuth authorization server? (a) A
single resource server or (b) several of them exposing different
resource types?
If the answer is (b) then how is a particular resource server identified
:
If your deployment is that complicated, even my discovery proposal is not
going to help you...
EHL
On Jul 14, 2010, at 18:37, Marius Scurtescu mscurte...@google.com wrote:
On Wed, Jul 14, 2010 at 3:22 PM, Torsten Lodderstedt
tors...@lodderstedt.net wrote:
I have a question
We implement the second option in our SSO protocol.
Am 15.07.2010 um 01:02 schrieb Brian Eaton bea...@google.com:
On Wed, Jul 14, 2010 at 2:59 PM, Torsten Lodderstedt
tors...@lodderstedt.net wrote:
The second request (as you pointed out in your original mail) is
currently used to verify
could then be used to
authenticate to the authorization server using something like Yaron's
recent proposal for client assertion authentication.
Cheers,
Brian
On Tue, Jul 13, 2010 at 5:55 PM, Kris Selden kris.sel...@gmail.com wrote:
Torsten Lodderstedt
[OAUTH-WG] Refresh tokens security
r-Lahav, E., Ed., Recordon, D., and D. Hardt, The OAuth 2.0 Protocol draft-ietf-oauth-v2-09, June2010.
[laws-of-identity]
Cameron, K., The Laws of Identity, May2005.
[openid-ax-1.0]
sp...@openid.net, OpenID Attribute Exchange 1.0 - Final, December2007.
[openid-connect]
Recordon, D. and E. Hammer-Lahav, Ed., OpenId Connect, May2010.
[request-by-reference]
Sakimura, N., Request by Reference ver.1.0 for OAuth 2.0
draft-sakimura-oauth-requrl-00, June2010.
TOC
Author's Address
Dr.-Ing. Torsten Lodderstedt
Deutsche Telekom AG
Email:
tors...@lodderstedt.net
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
A
Am 08.07.2010 um 18:29 schrieb David Recordon record...@gmail.com:
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
Is something as the user agent flow used in the wild today? What
security means are used their?
I wonder why we do not drop the user agent flow from the spec because of
security reasons. From my point of view, the web flow could be used to
achieve a similar behavior except the JavaScript
I essentially agreed, except in 3. the server should send back status
code 401 with a WWW-Authenticate header.
regards,
Torsten.
Am 01.07.2010 22:28, schrieb Eran Hammer-Lahav:
I think all servers must support the header. I don't think we can demand all
servers to support query or post
token, both, etc.). If you build consensus,
I'll gladly include it. Also, it is not clear to me how to add it to
the current token endpoint (unless we use a DELETE method).
EHL
*From:* Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
*Sent:* Tuesday, June 29, 2010 10:28 PM
*To:* Eran Hammer
resource response).
EHL
-Original Message-
From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Thursday, July 01, 2010 2:51 PM
To: Eran Hammer-Lahav
Cc: Marius Scurtescu; Justin Richer; oauth@ietf.org
Subject: Re: [OAUTH-WG] Support for query/body parameters (Was Re
you are right. So the only trustworthy way to enter credentials is an
external browser?
regards,
Torsten.
Am 28.06.2010 20:11, schrieb Marius Scurtescu:
On Fri, Jun 25, 2010 at 10:33 PM, Torsten Lodderstedt
tors...@lodderstedt.net wrote:
comment/question regarding the Embedded Browser
. This is far more than most HTTP servers will accept. So we are
pretty much required to use the body.
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Torsten Lodderstedt
Sent: Monday, June 28, 2010 12:26 PM
To: Marius Scurtescu
Cc: OAuth WG (oauth
Hi Eran,
what about token revocation? Will you include it?
regards,
Torsten.
Am 29.06.2010 08:56, schrieb Eran Hammer-Lahav:
Draft -09 is now posted. Main changes include:
o Fixed typos, editorial changes. Thanks to Dick for his useful feedback.
o Added token expiration example.
o
+1
Am 28.06.2010 07:37, schrieb Dick Hardt:
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
I would prefer (2) since authorization headers are the natural way to
handle authentication in HTTP. Different client credential mechanisms
can be represented by different authentication scheme (even
custom-defined). HTTP libraries typically have special support for
handling such headers and
, and these could be too large for
headers.
I think #1 makes sense.
Marius
On Mon, Jun 28, 2010 at 11:21 AM, Torsten Lodderstedt
tors...@lodderstedt.net wrote:
I would prefer (2) since authorization headers are the natural way to handle
authentication in HTTP. Different client credential mechanisms
would your proposal allow to issue and use HMAC Verification Keys in the
same way as the old token secrets, i.e. an AS would issue such keys
along with tokens to the OAuth client? A special key id could be used to
indicate this scenario.
regards,
Torsten.
Am 21.06.2010 09:04, schrieb Dirk
comment/question regarding the Embedded Browser scenario: Is the URL bar
and SSL verification symbols (lock + green bar) visible in that
scenario? Otherwise, the user has no chance to verify the identity of
the IDP/OAuth server. So there might be problems regarding password
phishing .
Am 16.06.2010 00:35, schrieb Brian Eaton:
On Tue, Jun 15, 2010 at 8:54 AM, Torsten Lodderstedt
tors...@lodderstedt.net wrote:
Wouldn't it be an alternative solution, if the AS first tries to
authenticate the user using SPNEGO within the Web Server flow? This should
work in the inhouse
I'm going to write an I-D for multiple access tokens. If someone else
would like to contribute, please contact me.
regards,
Torsten.
Am 17.06.2010 03:56, schrieb Eran Hammer-Lahav:
This use case seems to have some support for an extension, but enough
resistance for being added to core. I
- Explain that the separation between the authorization server and
resource server is out of scope
Why is this out of scope? I consider this a major improvement over
Oauth 1.0.
regards,
Torsten.
Am 15.06.2010 um 08:35 schrieb Eran Hammer-Lahav e...@hueniverse.com:
- Explain that the
ok, understood.
Am 15.06.2010 um 09:16 schrieb Eran Hammer-Lahav e...@hueniverse.com:
How they communicate is out of scope.
EHL
From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Monday, June 14, 2010 11:57 PM
To: Eran Hammer-Lahav
Cc: OAuth WG (oauth@ietf.org)
Subject
Wouldn't it be an alternative solution, if the AS first tries to
authenticate the user using SPNEGO within the Web Server flow? This
should work in the inhouse scenario. If it fails, it can fall back to
username/password auth..
Thoughts?
regards,
Torsten.
Am 15.06.2010 um 17:19 schrieb
+1
Am 14.06.2010 16:13, schrieb Tschofenig, Hannes (NSN - FI/Espoo):
Hi all,
Those who attended the last IETF meeting noticed that the actual working
group slots are quite short (around 2 hours). The feedback I got was
that this does not leave us with enough time to get work done. I
understand
and found the solution
for OpenID
(http://www3.interscience.wiley.com/journal/123441615/abstract),
which can be extended to geolocation. This would indeed allow to
authenticate on IMSI or MSISDN.
Igor
Torsten Lodderstedt wrote:
Hi Kevin,
what problems do you have
options are reasonable.
regards,
Torsten.
EHL
-Original Message-
From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Wednesday, May 26, 2010 11:26 AM
To: Eran Hammer-Lahav
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] in-app logout?
Hi Eran,
in my perception
some comments on the new draft from my side.
In my opinion, the raised abstraction level makes the spec harder to
read but more elegant :-) Rearranging conceptual statements and
endpoint/request descriptions would probably further improve
readability. For example, the end-user authorization
Am 11.06.2010 16:38, schrieb George Fletcher:
Makes perfect sense as we have the same model for our clients tokens:)
The one use case we've encountered is that this model revokes the
tokens for all clients with the same client_id. So if I've got three
of the same client installed (on three
Hi Eran,
you probably didn't notice my posting. What do you think about adding a
revocation request to the spec?
regards,
Torsten.
Original-Nachricht
Betreff:Re: [OAUTH-WG] in-app logout?
Datum: Wed, 26 May 2010 20:26:18 +0200
Von:Torsten Lodderstedt tors
Hi Christian,
in my opinion, the token should be digitally signed in order to detect
modifications. HMAC-SHA256 or RSA are good candidates for that. If you
really need encryption depends on your privacy and security requirements.
Typical token contents are: issuer, validity/expiration,
Hi Kevin,
what problems do you have with pre-paid users? Is your network unable to
authenticate them (by IMSI or MSISDN)?
regards,
Torsten.
Am 08.06.2010 18:31, schrieb Kevin Smith:
Hi David, Blaine,
We (the OneAPI group) have been looking further into OAUTH 2.0 and
would like to see how
no one in the WG having an opinion on this topic?
Am 09.06.2010 12:19, schrieb Torsten Lodderstedt:
Hi all,
I would like to see support in OAuth2 for the authorization of
arbitrary scopes in a single authorization flow for all kinds of
deployments. In some deployments this may require
+1
Am 10.06.2010 22:29, schrieb Eran Hammer-Lahav:
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.
My reason for
Am 10.06.2010 19:52, schrieb Eran Hammer-Lahav:
Pick or suggest new ideas:
* Endpoint used to interact with the end-user
End-user Endpoint
Front Channel Endpoint
Authorization Endpoint
End-User Authorization Endpoint
+1
User-Agent Endpoint
* Endpoint used to interact directly
using mechanisms provided by the HTTP protocol sound reasonable to me.
I see two questions:
1) Is 503 intended for that purpose?
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html says: The server
is currently unable to handle the request due to a temporary overloading
or maintenance of
1) +1
2) +1 - Oauth 1.0a had oob, why not for that purpose
3) I would rather add the user_code as optional URL parameter to the
device flow.
4) What about an additional best practices document?
regards,
Torsten.
Am 08.06.2010 19:46, schrieb Marius Scurtescu:
In order to properly support
Oops, I misread this point.
So +1 for 3), too.
regards,
Torsten.
Am 09.06.2010 18:45, schrieb Marius Scurtescu:
On Wed, Jun 9, 2010 at 12:42 AM, Torsten Lodderstedt
tors...@lodderstedt.net wrote:
3) I would rather add the user_code as optional URL parameter to the device
flow
BTW: the security threat I described in point 4) not only holds for
self-contained tokens but also for (super) handles. I consider it
especially dangerous if abusing a service causes costs for the end-user.
regards,
Torsten.
Am 03.06.2010 20:27, schrieb Torsten Lodderstedt:
I probably
+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:
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
Am 04.06.2010 19:45, schrieb John Kemp:
On Jun 4, 2010, at 1:35 PM, David Recordon wrote:
#4 should happen as part of #3.
How would ALL OAuth 2.0+ clients know to pass along the format if it is there?
I fail to see the problem with specifying an optional token format parameter in
-service signed characteristics in
the token itself that Torsten was talking about.
Would that work?
-- Justin
On Thu, 2010-06-03 at 14:27 -0400, Torsten Lodderstedt wrote:
I probably exaggerated a bit. It's not impossible but it is complex and
insecure for several reasons:
1
+1
Am 04.06.2010 23:38, schrieb Brian Campbell:
On Thu, Jun 3, 2010 at 9:20 AM, Peter Saint-Andrestpe...@stpeter.im wrote:
At least for the assertion flow, that's definitely true. At the interim
meeting we had some discussion about perhaps pulling the assertion flow
out of the base spec
I probably exaggerated a bit. It's not impossible but it is complex and
insecure for several reasons:
1) Such a super token would need to contain the union of all data and
permissions needed by all requested target services.
2) Not all services may by authorized to see all data contained in
Is there anyone who can answer my questions?
Am 30.05.2010 17:56, schrieb Torsten Lodderstedt:
I have some questions regarding the WWW-Authenticate header's scope
attribute.
The spec states
The scope attribute is a space-delimited list of URIs (relative or
absolute) indicating
is there a protocol of the interim meeting?
Am 01.06.2010 20:47, schrieb Peter Saint-Andre:
We discussed this a bit at the interim meeting, but I don't think we
came to any consensus.
On 6/1/10 12:46 PM, Torsten Lodderstedt wrote:
Is there anyone who can answer my questions?
Am
I have some questions regarding the WWW-Authenticate header's scope
attribute.
The spec states
The scope attribute is a space-delimited list of URIs (relative or
absolute) indicating the required scope of the access token for
accessing the requested resource.
Which of the scope URIs are
to be solved.
--
Andrew Arnott
I [may] not agree with what you have to say, but I'll defend to the
death your right to say it. - S. G. Tallentyre
On Sun, May 30, 2010 at 1:45 AM, Torsten Lodderstedt
tors...@lodderstedt.net mailto:tors...@lodderstedt.net wrote:
what is the advantage
in a particular
context cleanly solves the multiple service provider issue
-- Dick
On Mon, May 24, 2010 at 10:17 AM, Torsten Lodderstedt
tors...@lodderstedt.net mailto:tors...@lodderstedt.net wrote:
How many access tokens can be the result of a single OAuth
authorization flow
Hi Eran,
in my perception, there is some support on the list for having a request
to revoke refresh tokens. Will you add such a request to the
specification? Do you need a text proposal?
regards,
Torsten.
IMHO this would look more like a hack than proper protocol design. We need
a
Thank you all for your feedback on my posting. I will answer in a single
response.
To start with I want to clarfiy where I come from and what way my
thoughts went along. This will hopefully help to understand the
limitation of OAuth2 I want to address.
why different tokens?
At Deutsche
801 - 900 of 975 matches
Mail list logo
