I assume you are referring to the return_to URL?
Current libraries add all kinds of parameters to that URL, would you
be suggesting that the IdP does a GET on the return_to URL with
content-type of XRDS?
If so, then we should add that to the spec. I'd then like to get
clear on what would ne
Given that the RP has at least one URL, we can perform regular Yadis
discovery on it. (Likely, all of the RP's URLs point to the same
Yadis document.)
I don't think an extension to the protocol is needed.
On Oct 14, 2006, at 22:39, Dick Hardt wrote:
Currently there is no method for the IdP
Suggestion: sidestep the issue completely and in the spec -- and everywhere
else -- just call it OpenID provider. It's a simple concatenation of
"OpenID" and "service provider", so everyone gets it, but nobody will
associate it with SAML or federation or anything else.
-Original Message-
F
We call it "identity host" at NetMesh. It's close enough to "identity
provider" so people understand it quickly, but does not have the
"provider" part to it (duh).
On Oct 14, 2006, at 20:46, Scott Kveton wrote:
I would propose that the term "Homesite" be used when prompting the
user to type
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
_
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
fair
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
___
specs
There seemed consensus that being able to "bookmark" an RP at the IdP
was a useful feature for users.
The IdP would send a discovery_identifier to the RP's entry point
where it is expecting to get a POST from the login form.
OpenID Authentication then proceeds as normal. (this provides the
b
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
_
On 14-Oct-06, at 9:17 PM, Josh Hoyt wrote:
> 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
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
Here is another description of the protocol. As usual, it is terse
and concise. Hopefully this provides some insight.
Goal: RP would like to know which identifier to bind to a given
browser session, specifically, is this an identifier the RP already
knows about.
Assumptions:
The RP
On 14-Oct-06, at 8:45 PM, Scott Kveton wrote:
>>> 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
>> 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
> 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 us
On 13-Oct-06, at 12:59 PM, Drummond Reed wrote:
> Yesterday we established consensus that with OpenID, identifier
> portability
> is sacred.
>
> Today I'd like to establish consensus on the following "postulate":
>
> "To achieve identifier portability in OpenID, it MUST be possible
> for the
On 12-Oct-06, at 5:44 PM, Gabe Wachob wrote:
> *If* we are going to open up the terminology discussion, for me the
> terms
> "authenticating party" (formerly the "IDP") and "accepting
> party" (formerly
> the "relying party") seem more descriptive. The authenticating
> party issues
> authe
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"
Which vocabulary would you suggest we use?
The Identity Gang, IETF, OASIS, Liberty, InfoCard?
btw: Philip, perhaps you can configure your GoodLink Wireless
Handheld to send messages in plain text? ;-)
On 13-Oct-06, at 7:35 AM, Hallam-Baker, Phillip wrote:
> There is an established vocabulary,
On 13-Oct-06, at 12:04 AM, Martin Atkins wrote:
> Graves, Michael wrote:
>>
>>
>> I won't delve into where we are with respect to that capability here,
>> but want to suggest that maybe as we move to OpenID 2.0, and now
>> offer
>> portable IDs (as well as run-time chosen IDs selected at auth-
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 wi
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
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 anypl
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,
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,
>>
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
wo
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
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
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 b
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).
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 vanit
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
Jos
32 matches
Mail list logo
