Ok I think I got it. So I believe authentication would be redirecting the
end-user to the authorization server where he needs to authenticate himself.
Now, based on Facebook javascript SDK, it seems like steps D-F are implicit.
So once step C is done, D, E and F are not needed because a local javas
The issues token may contain different subject identifiers which come from
different issuing authorities; the new token may inherit from the source
assertions (aggregated) or these may be verified and passed on, there are cases
where both are methods are used. So we have thought about multiple
> I can't really understand how steps D, E and F works. Once I get the
> access_token in the fragment, what happens then?
In step C client receives from authorization server an access token in the
fragment part of the redirection URL, which the client provided to the
authorization server in step
The sets of use case that we have on various ongoing projects just have a
single subject (note that the single subject will be known by different
identifiers since there are jurisdictional requirements for this).
From: Zeltsan, Zachary (Zachary) [mailto:zachary.zelt...@alcatel-lucent.com]
Sent:
It does not need to have any normative references to 5849.
EHL
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Bill
de hÓra
Sent: Monday, August 30, 2010 5:47 AM
To: David Recordon
Cc: Tschofenig, Hannes (NSN - FI/Espoo); OAuth WG
Subject: Re:
On Mon, 2010-08-30 at 10:53 -0400, David Recordon wrote:
> On Mon, Aug 30, 2010 at 7:02 AM, Justin Richer
> wrote:
> Your first example is the textbook case, actually. You're
> still being
> asked to authorize TweetDeck, which is identified by its
> client_id
>
On Mon, Aug 30, 2010 at 7:02 AM, Justin Richer wrote:
> Your first example is the textbook case, actually. You're still being
> asked to authorize TweetDeck, which is identified by its client_id
> parameter. Say your laptop gets stolen -- you'd want to be able to
> differentiate between the two "
I'm more in favor of this alternative:
[1] http://www.ietf.org/mail-archive/web/oauth/current/msg02300.html
But I can see use cases for both: they basically look at the same
problem from both sides. If Marius would like to bring his draft up to
current spec, I would support its inclusion as a WG
Your first example is the textbook case, actually. You're still being
asked to authorize TweetDeck, which is identified by its client_id
parameter. Say your laptop gets stolen -- you'd want to be able to
differentiate between the two "TweetDeck" tokens listed on your
authorized apps account instead
Hi, I read the OAuth2 draft and I still have lots of doubts regard security
when talking about the User-Agent Profile.
I can't really understand how steps D, E and F works. Once I get the
access_token in the fragment, what happens then?
How can I avoid from a malicious user check the source of my u
[RFC2104] is a normative reference but isn't referred to in
draft-ietf-oauth-v2-10 and all the hmac stuff seems to be gone from
OAuth2 since 06 - so should the [RFC2104] reference be removed?
Bill
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.
On Fri, 2010-08-27 at 20:26 +, David Recordon wrote:
> This draft is now an Internet Draft and I'm curious if anyone has any
> feedback on
> it? http://tools.ietf.org/html/draft-recordon-oauth-v2-upgrade-00
>
replace
[[[
client_id
REQUIRED. The client identifier as described in Sectio
12 matches
Mail list logo
