Hi Hannes,
just submitted the document. I'm looking forward to a fruitful discussion.
regards,
Torsten.
Am 18.02.2011 13:34, schrieb Tschofenig, Hannes (NSN - FI/Espoo):
Hi Thorsten,
Hi all,
I am wondering what the status of the security draft is. The group is
eagerly waiting for it. I fea
A new version of I-D, draft-lodderstedt-oauth-security-00.txt has been
successfully submitted by Torsten Lodderstedt and posted to the IETF repository.
Filename:draft-lodderstedt-oauth-security
Revision:00
Title: OAuth 2.0 Threat Model and Security Considerations
Creation
Hi Kristoffer,
Hannes compiled the list :-)
regards,
Torsten.
Am 07.02.2011 22:10, schrieb Kristoffer Gronowski:
Hi Torsten!
Great that you compiled the list on WG items.
IMO there is one item missing and that is to create an optional formal
interface between the authorization server and the
Hi Eric,
I'm trying to understand the attack you described. I would expect any
client to mark its web sessions if it triggers an authorization process.
If so, the attacker would need to forge a valid client session in the
right state (authz process in progress) in order to place a sucessful
a
lternatively, some other discovery
mechanismus could be used, such as host-meta on the resource server.
Torsten Lodderstedt said:
I would expect the WWW-Authenticate header to return all the data required to
obtain the credentials/tokens, such as
WWW-Authenticate: MAC realm="somere
Long introduction - here are the documents:
A) Simple Web Discovery (SWD)
http://www.ietf.org/id/draft-jones-simple-web-discovery-00.txt
I consider authorization server endpoints and capabilities discovery an
important aspect and would be willed to review.
B) HTTP Authentication: MAC Aut
Hi Brian,
Mark McGloin, Phil Hunt and I are working on a security considerations
document. We plan to submit it to the working group in the next couple
of weeks. Your contribution would be highly appreciated. What would you
like to contribute?
regards,
Torsten.
Am 07.02.2011 19:09, schrieb
that's not the way WWW-Authenticate headers are used today. Instead the
resource server should return a single WWW-Authenticate header _per_
supported authentication scheme, such as
WWW-Authenticate: MAC realm="somerealm"
WWW-Authenticate: BEARER realm="somerealm"
furthermore, I think interdep
+1 for option 3, but would be fine with option 1, too
Both are quite similar, except 3 keeps the link between the OAuth
authorization server API (how to get a token) and the HTTP schemes used
to send the tokens to the resource servers. Since OAuth is becoming, in
my perception, the synonym for
nge credentials, such as password or
ticket for an access token. I mean the resource owner password flow is
already an example of such a flow.
regards,
Torsten.
-- Bob Gregory
On Tue, Jan 25, 2011 at 8:22 AM, Torsten Lodderstedt
mailto:tors...@lodderstedt.net>> wrote:
Zitat
m.free...@hp.com
Desk in Palo Alto: (650) 857-2581
Home: (408) 774-1298
Cell: (408) 348-7536
-Original Message-
From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Saturday, September 11, 2010 7:59 AM
To: Torsten Lodderstedt
Cc: Freeman, Tim; oauth@ietf.org
Subject: RE: [OAUTH-WG] Wh
es I'm aware of authenticate
users and I want to find a way to leverage them with OAuth to determine the
token's identity.
Regards,
Torsten.
Gesendet mit BlackBerry(r) Webmail von Telekom Deutschland
-Original Message-
From: Eran Hammer-Lahav
Date: Mon, 24 Jan 2011 15:25:38
T
Hi all,
I'm currently thinking about the integration of existing HTTP
authentication schemes with OAuth 2.0 for the purpose of end-user
authentication on the tokens endpoint. Possible candidates are "Digest"
for challenge-response-based username/password authentication and
"Spnego" for Kerber
done
Am 21.01.2011 06:38, schrieb Eran Hammer-Lahav:
Whoever is working on the security considerations section, please add this to
your list.
EHL
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Brian Eaton
Sent: Saturday, July 10, 2010 11:
o use an existing client authentication scheme such as
Digest, your solution creates a conflict, unless we define a way to
combine grant + Digest into one header.
EHL
*From:*Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
*Sent:* Tuesday, January 18, 2011 10:36 PM
*To:* Eran Hammer-Laha
ation
using, say, Basic or Digest? Seems like a complex framework for
combining schemes into one header.
EHL
*From:*Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
*Sent:* Sunday, January 16, 2011 10:55 AM
*To:* Eran Hammer-Lahav
*Cc:* OAuth WG
*Subject:* Re: [OAUTH-WG] Removal: credential
..@ietf.org] On Behalf Of Torsten
Lodderstedt [tors...@lodderstedt.net]
Sent: Sunday, January 16, 2011 1:54 PM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Removal: credential body parameters
Hi Eran,
you made some good points and I agree with most of your analysis. The way we
use BASI
+1 pro JSON
Am 16.01.2011 08:41, schrieb Eran Hammer-Lahav:
Why is the token returned in the fragment using form-encoding? This
makes no sense. It should be a JSON string for the following reasons:
1.All token responses should be the same, which will enable returning
structured responses in
wouldn't that mean to drop section 6 completely?
regards,
Torsten.
Am 15.01.2011 07:32, schrieb Eran Hammer-Lahav:
One of the main problems with OAuth in general has always been the
unsanitary mix of authorization and authentication ("it's an
authentication protocol... authorization protocol
Hi Eran,
you made some good points and I agree with most of your analysis. The
way we use BASIC in the current draft is not perfect, mainly because it
is a compromise. It was basically the attempt to be more HTTP compliant
while still supporting the parameter-based approach.
I would strongly
sten.
-- Justin
________
From: Torsten Lodderstedt [tors...@lodderstedt.net]
Sent: Wednesday, January 12, 2011 4:07 PM
To: Richer, Justin P.
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Re-Chartering: What Items to work on?
thank you for your feedback.
So you would suggest to l
intercepted signed request included
the hostname and port of the real resource server.
Zachary
*From:*Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
*Sent:* Wednesday, January 12, 2011 3:40 PM
*To:* Eran Hammer-Lahav
*Cc
t to revoke all "related" tokens at once, in which case
I think you need a different mechanism to do so.
-- Justin
From: oauth-boun...@ietf.org [oauth-boun...@ietf.org] On Behalf Of Torsten
Lodderstedt [tors...@lodderstedt.net]
Sent: Tuesday, Ja
+1 for option 2 because it will facilitates security analysis of the
protocol.
From a security analysis perspective, I think we need two views:
1) A structural view, describing the OAuth architecture (entities,
interfaces, communication paths) and
2) a flow-oriented view, which is built based o
request for getting access to the resource at the real server?
Zachary
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On
Behalf Of Eran Hammer-Lahav
Sent: Monday, January 10, 2011 4:46 PM
To: Torsten Lodderstedt
Cc: OA
Am 12.01.2011 01:43, schrieb Brian Eaton:
On Tue, Jan 11, 2011 at 2:44 PM, Torsten Lodderstedt
wrote:
Do you see any need to restrict the power of this token or is it as powerful
as the tokens obtained using the code? I'm asking because this token is sent
out without authenticating the c
>The frames timing issue is interesting, but doesn't it suggest a
profile where the whole code step is bypassed (e.g. by receiving code
and token)?
The user-agent profile callback URL should end up looking like this:
/callback#code=&token=
The token component is there so immediately return a u
the only difference I see is the code in the fragement will not show up
in HTTP referers.
Am 11.01.2011 22:21, schrieb Eran Hammer-Lahav:
But that's just an annoying implementation detail. If the only different now
between the hybrid and web server flows is one character ('?' vs '#'), and all
I just posted a new revision of
http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/.
Please consider it for the re-chartering process.
Additionally, Mark and me are still working on the security document. It
takes longer time than expected because of the topic's inherent
compl
Am 11.01.2011 06:44, schrieb Manger, James H:
- Authentication schemes
You propose to use the authentication scheme name "OAuth2" for the
WWW-Authenticate header but another scheme name "MAC" for the
authorization header. I've never seen such an asymmetric approach before.
Don't you think people
Hannes,
in my opinion, OAuth should stay a token-format independent protocol. So
intuitively, I would vote to work on this topic
within another group. Otherwise people might get the impression that
OAuth is directly tied to a certain token format.
regards,
Torsten.
Am 10.01.2011 10:19, schr
Eran,
- Authentication schemes
You propose to use the authentication scheme name "OAuth2" for the
WWW-Authenticate header but another scheme name "MAC" for the
authorization header. I've never seen such an asymmetric approach
before. Don't you think people get confused about that? Moreover, th
Hi Mike,
I've got some more comments on § 3.2 of your I-D.
paragraph 4: "Encrypting the token contents is another alternative ..."
How does token content encryption prevent the disclosure and abuse of a
token?
paragraph 5: "For those rare cases where the client is prevented from
observing
th
Independent of where this items belong to, the advice to only hand out
tokens to authenticated clients is stronger as required by the core
spec. There is a whole class of clients (native apps), which cannot keep
secrets
for the purpose of authentication.
Moreover, what is the benefit of authen
please include me on behalf of Deutsche Telekom
regards,
Torsten.
Am 05.01.2011 19:26, schrieb Eran Hammer-Lahav:
In the next few weeks I plan to survey existing and planned
implementations of each feature of the specification and those
components without at least 3 interoperable (or complian
Francisco,
Torsten,
> Another question: how does the server validate the
> identity/authenticity of the client? In other words, what
> does a malicious app prevent from using the URL and server
> of another native app?
Let me rephrase your question (correct me if I'm wrong): can
a malicious nat
+1
I have asked myself all the time why "oob" disappeared in OAuth 2.0?
Does Google use this feature?
regards,
Torsten.
Am 29.12.2010 23:53, schrieb Marius Scurtescu:
I would like to propose an OAuth 2 extension that helps native clients
close the loop after the approval page. The extension d
Francisco,
just to make sure I understood your paper correctly: even native clients
are required to have a backend server component, which receives the
authorization results and makes it available to the native client?
regards,
Torsten.
Hi all,
OAuth provides only weak security when used wi
Francisco,
the attack you described sounds very similar to session fixation
attacks. TLS (more specifically server authentication) is one way to
cope with spoofing in general (supposed the client has a reasonably CA
policy). So it should do in this case, too.
Validation of the redirect_uri a
+1
Am 14.12.2010 um 04:19 schrieb Eran Hammer-Lahav :
> I think the 'assertion' parameter should be moved into this draft and defined
> there. This will also facilitate its proper definition and status (required,
> singular, etc.).
>
> EHL
>
>> -Original Message-
>> From: oauth-boun
Am 13.12.2010 22:27, schrieb Marius Scurtescu:
On Mon, Dec 13, 2010 at 11:00 AM, Torsten Lodderstedt
wrote:
section 5.2
“The authorization server SHOULD NOT issue a refresh token when the access
grant type is an assertion or a set of client credentials.”
How shall the server determine
section 5.1.5 Assertion
I expected the assertion flow to be replaced by a general extension
model for new grant types (as described in section 7.4)?
But the the current text in section 5.1.5. requires every new grant type
to use the "assertion" parameter. Thus it supports additional assertion
Hannes,
will it be possible to dial-in?
regards,
Torsten.
Am 09.11.2010 05:47, schrieb Hannes Tschofenig:
Hi all,
at yesterday's security session we discussed ways on what to provide in the
security consideration for the OAuth specifications.
The plan was to have another session on Thursday,
Am 10.11.2010 08:00, schrieb Nicolas Williams:
[That is some cc list! Do you really need a cc list that large for this
thread? I've set the reply-to to just oauth@ietf.org (note: I'm NOT
subscribed to that list). Please honor the reply-to header. It's a
good idea to set reply-to when making a
.
Gesendet mit BlackBerry® Webmail von Telekom Deutschland
-Original Message-
From: Anthony Nadalin
Date: Tue, 9 Nov 2010 01:54:57
To: Torsten Lodderstedt; Hannes
Tschofenig
Cc: ab...@ietf.org; r...@ietf.org;
i...@ietf.org; sec...@ietf.org;
web...@ietf.org; x...@ietf.org;
kit...@ietf.or
n and considerations. The security considerations section of the
core spec can then be distilled from this document.
Regards,
Torsten.
Gesendet mit BlackBerry® Webmail von Telekom Deutschland
-Original Message-
From: Anthony Nadalin
Date: Tue, 9 Nov 2010 01:54:57
To: Torsten Lodderstedt; Hannes
Tscho
Hi all,
Mark McGloin and me have been working on OAuth 2.0 security
considerations for a couple of weeks now. Since we both cannot attend
the IETF-79 meetings, we would like to provide the WG with information
regarding the current status of our work. I therefore uploaded a
_preliminary_ versi
Martin,
great to see you contributing to the WG!
One question came into my mind: How do the other grant types (assertion,
username/password, refresh token) fit into your abstractions? The grant
type used also depends on the client and its capabilities, so just
returning a single URL pointing
Am 15.10.2010 19:52, schrieb David Recordon:
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 meeti
he WG planned to come to IETF-79?
regards,
Torsten.
Am 14.10.2010 19:40, schrieb Hannes Tschofenig:
No, there is not going to be a session at IETF79. We intentionally did not
request a slot because of the IETF78 experience.
On Oct 14, 2010, at 8:05 PM, Torsten Lodderstedt wrote:
Will there
Will there be a OAuth session at IETF-79? The agenda currently does
not contain such a session (http://tools.ietf.org/agenda/79/).
regards,
Torsten.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Prateek,
as I remember previous discussions, both design options (self-contained
short-living/one-time use tokens as well as random strings) shall be
feasible. So your contribution would helpful anyway.
regards,
Torsten.
Am 01.10.2010 18:36, schrieb PRATEEK MISHRA:
Torsten,
Brain Campbell
Bassically, your suggestion sounds reasonable to me.
The only thing I'm missing is discovery. As you pointed out in
http://hueniverse.com/2010/09/oauth-2-0-without-signatures-is-bad-for-the-web/
this is a major enabler for interoperable APIs and motivates the need
for signatures. Shouldn't we
Thank you for your advice. The Oauth security considerations are not finished
yet. They will handle the issues you raised, too.
Regards,
Torsten.
Am 30.09.2010 um 01:33 schrieb PRATEEK MISHRA :
> I read through v10 from the perspective of an implementor, and it seemed to
> me that properties
Am 27.09.2010 22:53, schrieb Dick Hardt:
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
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 use SSL, if one needs to go beyond this then
a reference to the
Am 25.09.2010 04:22, schrieb Eran Hammer-Lahav:
OAuth 2.0 is far from being published as an RFC. I estimate it is at
least 6 months away from reaching final IESG approval, if not a year.
This is mostly due to a significant effort needed in writing and
reviewing the security considerations sect
+1 for basic signature support
there is a need to protect end-users from token abuse by rogue resource
servers (see
http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-5, paragraph
3). Signatures based on a token secret is one way to prevent this kind
of attack.
Signature mechanisms
Am 20.09.2010 07:34, schrieb Luke Shepard:
Yes, Facebook is recommending the User-Agent flow for desktop
> applications. This works for them because access tokens issued by
> Facebook are not short lived, I don't think they expire. The desktop
> app does not need a refresh token.
>
> If th
Am 18.09.2010 01:28, schrieb Kris Selden:
Secrets on native apps are good! The key is (no pun intended) that the secret
not ship with the app. Each client should register for its own client_id and
secret when it is installed on the client machine.
Maybe I'm missing something but...
If it h
Am 16.09.2010 21:35, schrieb Marius Scurtescu:
On Thu, Sep 16, 2010 at 12:00 PM, Torsten Lodderstedt
wrote:
I don't know whether I understand you correctly. Are you saying that refresh
tokens only make sense in Web servers?
I was referring to the "web server" flow/profile.
Default for client password authentication is HTTP BASIC (cf.
http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-2.1)
regards,
Torsten.
Am 16.09.2010 15:52, schrieb mat...@gmail:
Hi experts,
I'm now developing OAuth2 server library in Ruby, rack-oauth2.
I have one question about error
I don't know whether I understand you correctly. Are you saying that refresh
tokens only make sense in Web servers?
regards,
Torsten.
Am 16.09.2010 um 18:04 schrieb Marius Scurtescu :
> On Wed, Sep 15, 2010 at 10:39 PM, Torsten Lodderstedt
> wrote:
>> Am 16.09.2010 um 05:
ote:
> I don't see why would you use the user-agent flow with a native
> application? Maybe the spec should suggest only the web server flow.
> The device flow would also work, but that's not part of the core spec.
>
> Marius
>
>
>
> On Wed, Sep 15, 2010
I'm wondering whether it makes sense to allow for the issuance of
refresh tokens by the user-agent flow.
Background of my considerations is the development of applications on
mobile devices (apps :-)). The draft suggests to either use the web
server or the user agent flow for the integration
direct access token revocation is optional but, if supported, then all
> associated assess tokens must also be revoked on a revocation of a
> refresh token.
>
> On Sun, Sep 12, 2010 at 4:13 AM, Torsten Lodderstedt
> wrote:
>> Stefanie,
>>
>> thanks for your com
I plan to work on that aspect. Do you (or someone else) want to contribute?
regards,
Torsten.
Am 14.09.2010 um 17:18 schrieb Mark Mcgloin :
> What about Security Considerations. I know some individuals have worked on
> it in the past - does it need a WG to complete
>
>
> Mark McGloin
>
> Han
token, attaching it to the evil user's
account.
9. Evil user can now access victim user data on his client account.
This is basically a session fixation attack.
EHL
-Original Message-----
From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Saturday, September 11, 2010 1:01 A
y thoughts?
Regards,
Stefanie
Am 08.09.2010 00:21, schrieb Torsten Lodderstedt:
I just submited the first version of my I-D for token revocation.
Link: https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/
The I-D proposes an additional endpoint, which can be used to revok
e or a shared data base to assure that
revoked (refresh) tokens are invalid.
=> Is this requirement really a MUST?
I don't think so.
Any thoughts?
Regards,
Stefanie
Am 08.09.2010 00:21, schrieb Torsten Lodderstedt:
I just submited the first version of my I-D for token revoca
Hannes,
what about discovery?
"Recommendations of commonly used Scope values" sounds to weak from my
point of view. I would rather suggest to work towards a clear definition
of scope syntax and semantics, including resource server identification.
Please note, I submitted a I-D on token revo
Doesn't step 7 require the evil user to know the client's secret?
Am 10.09.2010 17:06, schrieb Eran Hammer-Lahav:
1. Evil user starts the OAuth flow on the client using the web-server flow.
2. Client redirects the evil user to the authorization server, including state
information about the evi
I just submited the first version of my I-D for token revocation.
Link: https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/
The I-D proposes an additional endpoint, which can be used to revoke
both refresh and access tokens. The objective is to enhance OAuth
security by givin
+1
we just discussed the need for adding grant types in order support
Telekom-specific user authentication mechanisms. So this proposal comes right
in time :-)
regards,
Torsten.
Am 02.09.2010 um 23:27 schrieb Justin Richer :
> +1
>
> I've never liked the notion of not being able to extend
ensus as I was able to extract.
EHL
-Original Message-----
From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Wednesday, July 14, 2010 2:33 PM
To: Brian Eaton
Cc: Kris Selden; Eran Hammer-Lahav; OAuth WG
Subject: Re: [OAUTH-WG] issuing new refresh tokens
On Tue, Jul 13, 2010
(aggregated) or these may be verified and passed on,
there are cases where both are methods are used. So we have thought
about multiple tokens,, this winds up being more complicated and
traffic, the reason to not send directly is for user consent.
*From:* Torsten Lodderstedt [mailto:tors
seams option 2 took the lead by one vote.
1a II
1b I
1c
2 III
If no one objects by 08/29, I start writing the I-D based on option 2.
regards,
Torsten.
Am 16.08.2010 23:09, schrieb Torsten Lodderstedt:
Hi all,
I intend to submit a I-D for token revocation. Based on previous
discussions on
Am 28.08.2010 20:48, schrieb David Recordon:
On Sat, Aug 28, 2010 at 11:38 AM, Torsten Lodderstedt
mailto:tors...@lodderstedt.net>> wrote:
I think a bit more then just defining the delimiter is required in
order to make things work as you described (in a interoperable way).
+1 on making this a WG item
Am 27.08.2010 22:23, schrieb David Recordon:
Given our implementation experience, an iPad should use "popup" as
it's a full web browser on a reasonably large screen. Android and the
iPhone should use "touch". I'd be happy to add clarifying language in
the extension
d for it
yet in our production deployment.
On Sat, Aug 28, 2010 at 11:08 AM, Torsten Lodderstedt
mailto:tors...@lodderstedt.net>> wrote:
David,
any opinion on screen orientation and size?
regards,
Torsten.
Am 27.07.2010 12:51, schrieb Torsten Lodderstedt:
If I
peration on scope.
5.2.1 also defines how a protected resource can tell the client what
additional scope(s) are needed in order to make their request
successful. Standardizing the delimiter allows for this sort of
"addition" interaction.
--David
On Tue, Aug 24, 2010 at 10:41 P
David,
any opinion on screen orientation and size?
regards,
Torsten.
Am 27.07.2010 12:51, schrieb Torsten Lodderstedt:
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'
?
Another drawback is that the access token response has to be extended.
What kind of modifications of tokens do you have in mind? (as you commented
with 1c)
Regards,
Stefanie
Am 16.08.2010 23:09, schrieb Torsten Lodderstedt:
Hi all,
I intend to submit a I-D for token revocation. Based on previous
--- p.6 terminology/authorization server
" A server capable of issuing tokens after successfully
authenticating the resource owner and obtaining authorization.
The authorization server may be the same server as the resource
server, or a separate entity. "
Based
What data shall the issued token contain? Different identifiers and
also information about the different issuing authorities? Is the new
token's data inherited from the source assertions or are the assertions
just verified and the token data (incl. identity) are from other sources?
What do yo
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 <mailto:
1a and 1b. I suspect I
missed something; if not, I would change my vote to 1c or 1a+1c.)
Looking forward to seening the new I-D,
Igor
Torsten Lodderstedt wrote:
Hi all,
I intend to submit a I-D for token revocation. Based on previous
discussions on the mailing list and here at Deutsche
the
> letter of the core spec, which might take some wordsmithing.)
>
> On Monday, August 16, 2010, Torsten Lodderstedt
> wrote:
>> Paul Tarjan schrieb:
>>
>> Yes, I'm talking about 5.2.1
>>
>> For JSONP the user's browser is the client. It
n status code 200 for such requests. This keeps the spec simpler
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
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 h
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 w
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 :
> I generally agree more with Chuck, David and Brain E than I don't.
> But
?
regards,
Torsten.
Am 10.08.2010 um 19:57 schrieb Torsten Lodderstedt :
> 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 a
Am 11.08.2010 um 17:40 schrieb Christian Scholz :
> 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 u
Am 11.08.2010 um 17:40 schrieb Christian Scholz :
> 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 u
>>
>>
>
>> 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 sort of extended AS) to use or it might be
> discovered via webfinger or similar means.
>
> The process for requeste
Am 11.08.2010 um 12:40 schrieb Torsten Lodderstedt :
> 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
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
were:
>>
>> 1. It's already coded this way.
>> 2. It's the most efficient way 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 w
t;
>> thread). The answers that I've got were:
>>
>> 1. It's already coded this way.
>> 2. It's the most efficient way of doing that, because that relay.html page
>> is static and can be cached by a browser.
>>
>> None of the answers
801 - 900 of 1141 matches
Mail list logo
