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-
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
Yes. Or any of the other defined algorithms for obtaining the XRDS
file, given the return_to URL.
On Oct 14, 2006, at 23:50, Dick Hardt wrote:
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
Hi Drummond,
Don't forget we'll need some way for an IdP to discover the return_to
URL from an RP in the IdP-initiated scenarios (I'd suggest a META or
LINK tag in the web page that the RP displays for accepting a login,
so an IdP (or browser plugin agent!) can discover this by parsing
the
Hi Chris
Would you clarify these IdP initiated scenarios?
I envisioned that an IdP learned of an RP from the user have an
initial interaction with the RP. The IdP would then save the RP URL
for later use in case the user wanted to go back to the RP directly
from the IdP.
-- Dick
On
Hi Dick,
1. IdP's advertising a list of sites that accept OpenID - like the
way PayPal list stores that accept their currency I guess. It's
annoying to a user to have to come back to the place they just
clicked in order to click a second time in order to go where they
wanted to in
I'd really prefer not to change terminology in the spec right now.
Seems like something we should have thought about four months ago versus
a week after we said it would be final. There is nothing saying user
friendly terms that map to spec terms can't be created for the time
being. I do
After re-reading this, other messages, and Dick's latest post, I
strongly feel that we should make the change to support both the
portable and IdP-specific identifiers within the protocol.
The two most compelling reasons to me are that it has the fewest
conceptual changes from OpenID Auth 1.x and
Hi David,
What is the rush for? There's a lot of unhappy people here due to
missing protocol elements.
I for one believe the lack of privacy considerations is an entire
OpenID killer.
Is there a reason why you've omitted my IdP-initiated login proposal
from your short list (also known as
Hi Chris,
The rush is that 2.0 has been in a drafting phase for almost six months
now, with draft five being posted at the end of June. While we
certainly can continue taking the time to make everyone happy, we
ultimately will never have a finished specification.
Rather I think it is important
10 matches
Mail list logo