On Mon, Jun 7, 2010 at 5:31 PM, Chuck Mortimore
wrote:
> Note sure I follow this Marius:
>
> “What can happen is that exmple.com/back can pretend to be
> example.com/back, but registration does not help in this case.”
>
> I believe it does help in this case, as the Authorization server can
> valid
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
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
Note sure I follow this Marius:
"What can happen is that exmple.com/back can pretend to be
example.com/back, but registration does not help in this case."
I believe it does help in this case, as the Authorization server can validate
the registered redirect_uri vs. the requested redirect_uri. H
John,
>> access_token=saml.fhHFhgf6575fhgFGrytr
> What is the advantage of doing it this way over having a separate field?
Client simplicity (code and mental model).
> What if the format is a URI?
That is a choice between the AS and PR that is irrelevant to the client app --
so why should th
On Fri, Jun 4, 2010 at 9:49 PM, Andrew Arnott wrote:
> The user agent flow indicates that the redirect_uri SHOULD be preregistered
> with the auth server for a given client. I would like to suggest that the
> SHOULD here be changed to MUST. Unless I'm missing something, without a
> preregistered
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 cases already (or am I reading
the wrong section). In Figure 6,
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
The username/password flow is designed to work in a situation where there is no
web browser available. At least at Facebook, none of our clients implement
captcha - it doesn't really make sense in many contexts.
A provider is still welcome to offer a non-standard captcha support but it
shouldn'
I would prefer to see it in the core spec.
On 2010-06-07, at 7:32 AM, Thomas Hardjono wrote:
> Thanks Dick. I was just kinda confused: if the Assertion Flow was already in
> the WRAP draft and now in the core spec (OAuth2.0-draft-05), what do we gain
> from separating it off again.
>
> /thom
On Jun 6, 2010, at 11:14 PM, Manger, James H wrote:
> OAuth2 has a field for AS-to-PR communications via (but opaque to) the
> client: access_token. Any format indication (like a variety of other details)
> that an AS wants to convey to the PR via the client app should be *inside*
> this existi
Thanks Dick. I was just kinda confused: if the Assertion Flow was already in
the WRAP draft and now in the core spec (OAuth2.0-draft-05), what do we gain
from separating it off again.
/thomas/
__
> -Original Message-
> From: Dick Hardt [mailto:
I still need to catch up on the list (I took a little break). I plan to post a
new draft this week incorporating many editorial changes discussed at the
interim meeting. I am also planning of removing some non-stable features (such
as discovery and signatures) from the draft and moving them to n
Rick, ...
On Sat, Jun 5, 2010 at 12:45 PM, Rick Olson wrote:
> How else are you preregistered with the auth server?
I don't understand the question, sorry.
> Why can't you
> just return the temporary code and rely on the JS or Desktop app to
> make another call to get the access token? JSONP
(resending to DL due to apparent DL failure over the weekend... I know Dick
and Luke already received my email because they were individual recipients
as well... I don't know if the DL received their replies or not)...
Great discussion, all. I am also for an optional parameter that's part of
the
In WRAP, there was a CAPTCHA in this profile, but I don't see it in the
latest OAuth 2.0 draft. Since I've already implemented the CAPTCHA stuff
from WRAP, I'll leave it there if the OAuth 2.0 is likely to pick it up, or
rip it out now if OAuth 2.0 decided it wasn't necessary.
Does anyone from th
>From the spec:
The client makes the following request at an arbitrary but reasonable *interval
*which MUST NOT *exceed the minimum **interval rate *provided by the
authorization server (if present via the interval parameter).
I know what an interval is, and I know what a rate is. But "interval
The web server flow includes an optional scope parameter in a success
response. The user agent flow seems to be missing that. If a single auth
server supports both flows, and actually leverages the capability in the web
server flow to change the set of granted scopes from the requested ones by
se
OAuth2 has a field for AS-to-PR communications via (but opaque to) the client:
access_token. Any format indication (like a variety of other details) that an
AS wants to convey to the PR via the client app should be *inside* this
existing field.
Defining an optional prefix for access_token value
OAuth 2.0 Draft 5 Issues List
Intro:
- Purposes/use cases should appear in intro
- Describe role wrt OpenID and auth schemes ??
- Requirements should be removd out of intro
Intro should describe goals and possibilities of OAuth
- Requirements is a limited set, but it should be clarified that they
I hope so.
On 2010-06-06, at 3:22 PM, Thomas Hardjono wrote:
> Apologies for another newbie question: is the design-intention underlying the
> Assertion Flow in OAuth2.0-draft-05 the same as that in the WRAP draft
> (draft-hardt-oauth-01)?
>
> /thomas/
>
>
Nat,
> On the other hand, you are starting to think of it as a generic "include"
> mechanism, are you?
Yes. That feels like the simplest mental model for this functionality, and the
simplest way to specify it.
--
James Manger
___
OAuth mailing list
O
Apologies for another newbie question: is the design-intention underlying the
Assertion Flow in OAuth2.0-draft-05 the same as that in the WRAP draft
(draft-hardt-oauth-01)?
/thomas/
__
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:o
Ah, I am starting to getting your point.
I was assuming that the text was just dealing with this particular flow,
possibly a separate standalone document as David R. suggested.
On the other hand, you are starting to think of it as a generic "include"
mechanism, are you?
I agree that would be actu
24 matches
Mail list logo
