With a good deal of work from both Josh and I this past week, we now
have Draft 10
(http://openid.net/specs/openid-authentication-2_0-10.html)! While I
previously proposed this be the final draft, the delegation proposal is
still being actively discussed and it is quite important consensus be
On 10/13/06, Drummond Reed [EMAIL PROTECTED] wrote:
So whether it's in the spec formally or not, I don't really care. But the
spec MUST contain details on the precautions a RP should take.
Yup.(Got that, editors?)
http://openid.net/specs/openid-authentication-2_0-10.html#anchor38
Josh
On 10/13/06, Chris Drake [EMAIL PROTECTED] wrote:
DR CASE 1: the protocol supports only IdP-specific identifiers and no
portable
DR identifiers.
DR RESULT: IdPs can achieve identifier lockin. Not acceptable. End of Case 1.
Please explain? If I've got an OpenID URL (eg: my vanity domain),
Brad Fitzpatrick wrote:
Counter-argument: but OpenID 1.1 does have two parameters: one's just in
the return_to URL and managed by the client library, arguably in its own
ugly namespace (not IdP/RP managed, not openid., but something else...
the Perl library uses oic. or something). So
Hi Josh,
I do not believe the RP needs to know the IdP-specific identifier ever
(worse: I think it should never be allowed to know it, or even be
allowed to see it!).
JH Why not?
PRIVACY. Page back and read trough my posts to this list for the
intricate details.
JH Where is power being
Should you wish to track changes to the website or specifications, feel
free to join this list.
http://openid.net/mailman/listinfo/commits
--David
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
Currently the default encryption type for openid.session_type when
creating a new association is no-encryption. This stems from OpenID
Authentication 1.1 where when the parameter was not included in the
request it meant no encryption. I'd recommend that this default value
be changed to DH-SHA1
Chris,
I totally agree that: a) OpenID Authentication 2.0 should support yours
scenario of IdP-initiated login, and b) that this enables a whole range of
privacy solutions, many of which can be supported by IdP innovation.
If IdP-initiated login were the only use case, then only one identifier
On 13-Oct-06, at 7:45 PM, Drummond Reed wrote:
And despite all the but it can't be stateless without two!
noise, it
actually can: you put the portable identifier in the return_to
URL and
verify it again when you get the signature back from the IdP.
That is,
verify the
On 14-Oct-06, at 7:28 AM, Chris Drake wrote:
JH Where is power being granted to the RP? It has pretty much none.
JH It *does* have responsibility, but only as much as is necessary to
JH make the protocol work.
If RPs are allowed to build up linked portfolios of everyones
identifiers, they
Also note that URL parameters are not secured by TLS in HTTPS.
-- Dick
On 13-Oct-06, at 3:57 AM, Chris Drake wrote:
Hi All,
Just so everyone remembers: GET encoded http://; URLs usually
appear en-mass in public lists (from proxy cache logs). If you don't
want to POST data anyplace,
Dick,
While it is true that the IdP should still check that they are bound,
except in the case when it is directly authoritative for both, the RP
should provide the IdP with what the user entered as a hint to what
claim the End User is wishing to make. Just sending the non-portable
identifier, as
On 14-Oct-06, at 7:36 PM, Recordon, David wrote:
Dick,
While it is true that the IdP should still check that they are bound,
except in the case when it is directly authoritative for both, the RP
should provide the IdP with what the user entered as a hint to what
claim the End User is
Would you elaborate on those use cases? The current draft does not
support this.
-- Dick
On 13-Oct-06, at 8:52 AM, Granqvist, Hans wrote:
I can see potential use-cases where Alice doesn't want the
idp to know what her portable URL is. This would not work
if the protocol requires both as
I would propose that the term Homesite be used when prompting the
user to type in their IdP. I think the term Identity Provider is
overloaded and not user friendly.
As per my last email I feel the same way about identity provider as well
... I agree with Dick; too overloaded and not user
I kinda get homesite, but I don't understand the thinking behind
membersite: What is this site supposed to be a member of?
It was a member of the network of sites running the protocol.
Membersite sounds too much like you have to join some club to participate.
I feel the same way about
On 10/14/06, Dick Hardt [EMAIL PROTECTED] wrote:
Since the request is not signed and flows through the user, the IdP
does not know the request message has not been modified. If the IdP
assumes the two identifiers are bound, then a malicious user can
pretend to be a different user from the same
Motivating Use Case:
When an RP is storing attributes at an IdP and does not want to
authenticate the user, the RP may want the user to remain at the IdP.
Other extensions may want similar functionality
Proposal:
A missing openid.return_to is NOT an error.
Affects:
5.2.3
10.1
Currently there is no method for the IdP to learn anything about the
RP. As a path for extensibility, would anyone have a problem with
having an optional parameter in the AuthN Request for the location of
the RP's Yadis document?
-- Dick
___
Clarification:
auth_age allows an RP to specify how long it has been since the IdP
has authenticated the user. The use case of this is for sites that
have different auth_age requirements for different sections of the
site. For example, amazon.com lets me browse around the site with an
Given that the spec uses the word identifier throughout, it would
make sense that the parameter would be called that.
Perhaps in changing what the parameter contains, we can rename it,
and keep openid.identity for backward compatibility?
-- Dick
21 matches
Mail list logo
