I think the 2.0 spec extension mechanism could handle signed
credentials. For example, credentials=s where s is of
a (string) format that contains a type + signature, say
credentials=OATHVIP:WW91IGhhZCB0byBjaGVjaywgZGlkbid0IHlvdT8gOyk=
The format could also further specify mechanism types,
Chris Drake wrote:
Hi All,
1. Amazon asks the IdP Please assert this user is not a Robot
How can it trust this occurred?
2. Amazon asks the IdP Please re-authenticate this user, via
two-factor, two-way strong authentication
How can it trust *this* occurred?
The IdP can *say*
Behavior needs to be specified before it can be recommended.
So the spec MUST specify how to deal with the multiple
parameters before it can set the use thereof as NOT
RECOMMENDED.
Hans
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Recordon,
On 10/6/06, Martin Atkins [EMAIL PROTECTED] wrote:
* The IdP returns a document naming its authentication endpoint (in the
URI field) and a special anonymous token as openid:Token. openid:Token
may be the same as the public identifier from the previous step, but
this is not required.
+1. Josh is right. Ultimately there are three identifiers involved in all
interactions between the User, the RP, and the IdP:
1) User-Presented-Identifier (UPI): the identifier entered by the User at
the RP.
2) RP-Persisted-Identifier (RPI): the identifier that will be persisted by
the RP in
Hi Martin,
This is getting very close to what I believe is the main important
thing we need in the spec to facilitate privacy, true SingleSignOn,
and to help avoid confusing users by getting them to key IdP URLs.
The only tweak I would like to see is right at the start, and is
implemented using
On Fri, 2006-10-06 at 13:26 +1000, Chris Drake wrote:
Is my understanding accurate: OpenID is unable to support single sign
on. If not - lets assume it's 9am. I just signed on. I can visit
RP#1 then RP#2 then RP#3 and go back and forth all day without
hindrance, until I next sign off - yes?
I'd like to amend my proposal for changing the delegation mechanism:
Revised Proposal
As it stands, openid.identity is the identifier by which the IdP
knows the user. There is no parameter by which the RP knows the user.
I propose to add a field called openid.rp_user_id in
CHRIS DRAKE'S PROPOSED FLOW
1) User *enters* UPI, but a Discovery Agent intercepts this: UPI does
*not* get posted to RP
2) Discovery Agent sends UPI to IdP
3) IdP authenticates against UPI
4) IdP selects appropriate RP-specific IPI
5) IdP initiates authentication with RP using IPI
Kind
From http://www.lifewiki.net/openid/SeparateIdentifierFromIdPToken
(change #3):
Impact on XRI-based auth:
An XRI is, for this purpose, a URI that can be resolved into a URL at
which we can do Yadis discovery. Once Yadis discovery begins, flow
continues as in the original proposal, where
+1 to Kevin's point here -- no second discovery step is needed with an XRI.
=Drummond
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Kevin Turner
Sent: Friday, October 06, 2006 1:58 PM
To: specs@openid.net
Subject: Re: [PROPOSAL] Separate Public
On 10/6/06, Granqvist, Hans [EMAIL PROTECTED] wrote:
Can you propose this in terms of diffs to the current draft so
it is glaringly obvious what the proposal means?
Sure.
Also, I think this diffs to current draft can be most useful
for all proposals as it cuts through the various semantic
Well that is something that if the spec dictates where to place/format a
request nonce, an IdP could recognize and remove it. I do agree though
that it is getting close to having too many implications.
--David
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
On Fri, 2006-10-06 at 16:34 -0700, Drummond Reed wrote:
Let me play the dumb customer here and say:
* A whole lot of real-world users would love OpenID-enabled bookmarks.
* A whole lot of websites would love to offer them.
* A whole lot of IdPs would love to provide them.
Okay Customer, if
On Fri, 2006-10-06 at 16:34 -0700, Drummond Reed wrote:
Let me play the dumb customer here and say:
* A whole lot of real-world users would love OpenID-enabled bookmarks.
* A whole lot of websites would love to offer them.
* A whole lot of IdPs would love to provide them.
Kevin Turner
At David's suggestion, to make it easier to follow, I've posted what I
believe is a consolidated delegate proposal at:
http://www.lifewiki.net/openid/ConsolidatedDelegationProposal
This incorporates Josh's original, Martin's, Josh's amendment, and my
amendment to Josh's.
Josh and
KT On Fri, 2006-10-06 at 16:34 -0700, Drummond Reed wrote:
Let me play the dumb customer here and say:
* A whole lot of real-world users would love OpenID-enabled bookmarks.
* A whole lot of websites would love to offer them.
* A whole lot of IdPs would love to provide them.
KT Okay
17 matches
Mail list logo
