RE: Re[2]: Strong Authencation (was [PROPOSAL] authentication age
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, signer identity, and algorithm(s) used if those are not part of the definition of 'credentials'. Hans -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Drummond Reed Sent: Thursday, October 05, 2006 2:26 PM To: 'Chris Drake' Cc: specs@openid.net Subject: RE: Re[2]: Strong Authencation (was [PROPOSAL] authentication age Chris, Great examples. Signed credentials makes lots of sense. OpenID AuthN 2.0 doesn't handle them yet but I can completely understand them in the roadmap. =Drummond -Original Message- From: Chris Drake [mailto:[EMAIL PROTECTED] Sent: Thursday, October 05, 2006 10:51 AM To: Drummond Reed Cc: specs@openid.net Subject: Re[2]: Strong Authencation (was [PROPOSAL] authentication age Hi Drummond, Example1: RSA would provide a signed response indicating that the user correctly entered the SecurID token code. Example2: The RP would have the public key of the company that supplies the fingerprint scanning hardware (although some extra thought as to how a fingerprint ultimately matches to an Identity is required, which will need an entirely different information flow to Example1). Is Dick a vendor himself? he no doubt knows other ways. Kind Regards, Chris Drake, =1id.com Friday, October 6, 2006, 3:19:44 AM, you wrote: DR Dick, DR You say, The strong authentication will be supplied by a vendor DR that has DR been certified to provide standardized levels of authentication. The DR IdP will often NOT be the strong auth vendor. DR Can you explain how this might work, i.e., how can the RP have a DR relationship directly with the strong auth vendor and not the IdP? DR Would the DR IdP be outsourcing authentication to the strong auth vendor? In DR which case, DR isn't the strong auth vendor the IdP? DR =Drummond DR -Original Message- DR From: [EMAIL PROTECTED] DR [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt DR Sent: Thursday, October 05, 2006 9:36 AM DR To: Gabe Wachob DR Cc: specs@openid.net DR Subject: Strong Authencation (was [PROPOSAL] authentication age DR The vision I have is that strong authentication to your IdP will be DR common in the future. DR The strong authentication will be supplied by a vendor that has been DR certified to provide standardized levels of authentication. The IdP DR will often NOT be the strong auth vendor. DR The RP will have a trust relationship with the vendor, likely DR through a vendor consortium that delegates to vendors that their DR product is certified, ie. the RP will not need to trust each vendor, DR just the certification body. DR I would hope that OpenID can be extended over time to be able to DR move around these types of strong auth assertions. DR -- Dick DR On 4-Oct-06, at 8:41 PM, Gabe Wachob wrote: Chris- As someone who has recently come from working in the financial sector (Visa), its clear that OpenID is NOT intended for authentication where the *relying party* cares about how the authentication is performed. At places like Visa and for home banking, this means that OpenID, without something more, is clearly a non-starter. These relying parties want to know exactly how their users are being authenticated because their business is all about risk management and creating business opportunities around very good knowledge of the risk profile of each transaction type. That all being said, I believe it should be possible to layer on OpenID a form of IDP control such that a relying party can require a certain class or group of IDPs be used when presenting authentication assertions to them. The actual *policy* for how these IDPs are approved is probably orthogonal to the protocol spec, but secure identification of those IDPs (relative to some trust root, etc) could probably be made into an extension usable for those parties who want it. My guess is that culturally, most people involved in OpenID have *not* been interested in addressing these concerns. However, expectations need to be better managed around these sort of relying-party cares scenarios, because its not obvious without actually reading the specs themselves... -Gabe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Drake Sent: Wednesday, October 04, 2006 8:26 PM To: Kevin Turner Cc: specs@openid.net Subject: Re[2]: [PROPOSAL] authentication age Hi Kevin, Sounds like you're leaning towards a root authority for IdPs who can
Re: Strong Authencation (was [PROPOSAL] authentication age
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* it did, but would RPs prefer a stronger role to encourage adoption? (eg: #1 - the RP provides the captcha, and the hash of the solution, while the IdP returns the solution, or #2 - the RP provides a nonce and later looks for this nonce in the IdP's also-signed-by-the-authentication-vendor-technology response) i.e.: It might get ugly to try and add this stuff in later if we've not catered up-front for these kinds of interchanges. These use-cases seem like a good one, in that it's something that's actually *verifiable*, rather than relying on a trust relationship that probably doesn't exist between RP and IdP. I still don't think this should be in the core spec — core OpenID Auth should be simple — but we should make sure that it's possible to add it via extension and if it isn't adjust the way extensions work to make it possible. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Request for comments: Sorting fields in signature generation-Call for votes
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, David Sent: Wednesday, September 27, 2006 1:13 PM To: Josh Hoyt; Marius Scurtescu; Brad Fitzpatrick Cc: specs@openid.net Subject: RE: Request for comments: Sorting fields in signature generation-Call for votes I don't think multiple parameters with the same name should be completely disallowed, rather that section 7.1 should strongly discourage their use. I agree that from the core authentication standpoint they aren't needed today, though do understand that in the future there may be a compelling use case for them. I believe the simplicity that is offered from not supporting them out weighs the benefit of form handling with existing forms. So +1 to tightening up section 7.1, but -1 to it specifically allowing multiple parameters with the same name. I believe the wording should be such that it is strongly NOT RECOMMENDED that extensions to OpenID Authentication utilize GET or POST parameters with the same name. Brad, thoughts? --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh Hoyt Sent: Wednesday, September 27, 2006 12:20 PM To: Marius Scurtescu Cc: specs@openid.net Subject: Re: Request for comments: Sorting fields in signature generation -Call for votes On 9/27/06, Marius Scurtescu [EMAIL PROTECTED] wrote: please keep in mind that we are not asking for some fancy new technology or feature, just conformance with a very basic an wide spread convention of handling parameters in HTTP/HTML. As Kevin pointed out, we are not working on the HTTP/HTML form processing specification. We are working on an authentication protocol. Restricting the protocol to forbid multiple parameters with the same name does not break conformance with anything. I think that we have discussed the majority of the technical issues regarding multiple parameters with the same name. I could respond to your individual points, but I don't think that would get us any closer to agreement. Can we get +1/-1 on multiple parameters with the same name from people without @sxip.com or @janrain.com e-mail addresses? Clearly, we (JanRain) are -1. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [PROPOSAL] Separate Public Identifier from IdP Identifier
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. Anonymous is not a good thing to call this. What IdP-driven identifier selection does is let the IdP help the user choose an identifier. In no way is the response any more anonymous than an identifier that was typed in by the user. It is true that one of the motivations for this feature is the great improvement in the user experience for site-specific identifiers, but the IdP could just as well return a cross-site identifier for the user. Sorry to go on about terminology, but I think it's important for understanding what's really going on. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: [PROPOSAL] Separate Public Identifier from IdP Identifier
+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 order to recognize the User when next the User returns. 3) IdP-Persisted-Identifier (IPI): the identifier persisted by the IdP against which the IdP will authenticate the user. Here's a simple analysis of how these are used during the different flows: OPENID 1.X 1) User enters UPI 2) RP discovers IPI (if any -- otherwise UPI = IPI) 3) RP sends IPI to IdP 4) IdP authenticates against IPI 5) IdP responds with IPI JOSH'S PROPOSED FLOW 1) User enters UPI 2) RP sends UPI to IdP 3) IdP discovers IPI (if any -- otherwise UPI = IPI) 4) IdP authenticates against IPI 5) IdP responds with UPI OPENID 2.0 DIRECTED IDENTITY FLOW 1) User enters UPI (where UPI = identifier of directed identity server) 2) RP sends special UPI (http://openid.net/identifier_select/2.0;) to IdP 3) IdP discovers IPI 4) IdP authenticates against IPI 5) IdP responds with RPI OPENID 2.0 XRI CANONICAL ID FLOW 1) User enters UPI (XRI i-name) 2) RP discovers RPI (XRI i-number = CanonicalID) 3) RP sends RPI to IdP 4) IdP authenticates against RPI (RPI = IPI) 5) IdP responds with RPI * On this basis, it seems the solution is for the protocol to clearly recognize all three identifier types. This would: a) Support all four flows above. b) Enable RPs and IdPs to all do the right thing at the right time with the right identifier c) Eliminate confusion over which identifier is doing what in each flow. So we would go from openid.identity, which is currently overloaded, to: openid.identity = IPI openid.persist = RPI openid.display = UPI Or whatever names everyone can agree on. =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh Hoyt Sent: Friday, October 06, 2006 10:34 AM To: Martin Atkins Cc: specs@openid.net Subject: Re: [PROPOSAL] Separate Public Identifier from IdP Identifier 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. Anonymous is not a good thing to call this. What IdP-driven identifier selection does is let the IdP help the user choose an identifier. In no way is the response any more anonymous than an identifier that was typed in by the user. It is true that one of the motivations for this feature is the great improvement in the user experience for site-specific identifiers, but the IdP could just as well return a cross-site identifier for the user. Sorry to go on about terminology, but I think it's important for understanding what's really going on. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re[2]: [PROPOSAL] Separate Public Identifier from IdP Identifier
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 OPTIONAL (at the RP) pure client-side stuff (plain HTML or JavaScript). The server-side tweak I'd like to see would be this: An ***IdP*** can *initiate* the OpenID login with the RP using openid:Token. How the User arrived at the RP with this token is not the concern of the RP. (could be javascript, browser plugins, participating IdP helper CGIs, or even the RP itself). The point is - the guts of the authentication process remains unchanged and is backwards compatible, but all the privacy-invasive components that live at the RP are thus made *optional*. Simple as that. User only needs to remember and use one ID. User only needs to type it one time each day (or however long they elect to stay logged on for). Datamatching and privacy invasion are eradicated. No need to key custom IdP anonymity URLs ever. Even facilitates double-blind anonymous logins (with inclusion of a simple RP nonce extension). Win-win-win. Kind Regards, Chris Drake =1id.com Saturday, October 7, 2006, 2:49:17 AM, you wrote: MA Dick Hardt wrote: I like making all identifiers work the same way. The wording around directed identity is somewhat confusing. Would be clearer if there was a complete description of what happened. ie. complete the transaction. In Directed Identity, the RP needs to do discovery on the identifier provided to make sure the IdP is authoritative for it. MA Perhaps I've misunderstood how directed identity works, but I figured MA the flow would work as follows: MA * The RP initiates Yadis discovery on http://anon.myidp.com/ MA * The IdP returns a document naming its authentication endpoint (in the MA URI field) and a special anonymous token as openid:Token. openid:Token MA may be the same as the public identifier from the previous step, but MA this is not required. MA * The RP initiates OpenID auth to the named endpoint using the openid:Token. MA * The IdP notes that the special anonymous token has been used, but it MA knows who the remote user is (via Cookies, for example) so it can MA generate an identifier and remember that it belongs to that user/RP combo. MA * IdP responds to RP with the generated public identifier (which *is* MA publically resolvable, of course.) MA * RP resolves the IdP-provided public identifier, where the IdP will MA provide for Yadis discovery and specify that it is authoritative for MA that URL. MA * We're done. MA The important thing is that, just as I've separated the public MA identifier from the IdP token (or handle, if you like), this separation MA also applies to the IdP-generated public identifier. MA (sorry that this is a bit rough. I've not really spent the necessary MA amount of time preparing the above and I'm in a hurry, so if there are MA spots where I'm not clear I apologise and I'll clarify later! :) ) MA ___ MA specs mailing list MA specs@openid.net MA http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Adoption questions
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? This depends almost entirely on the configuration of the RPs involved, but I think the situation you describe is quite doable. Privacy: during any hypothetical overheard lunchtime conversation between The CEO of RP#1 and the CEO of RP#2 - nobody's ever going to hear this fragment of conversation: ... yeah - that troublemaker is one of our users too ... - or are they? Being able to identify troublemakers across sites is one of the chief features of a system like OpenID. It's what enables reputation systems and helps content providers break out of silos. However, if as a user, you don't like that feature, you can use directed identity with OpenID. This requires using an IdP with enough other users to provide you with some degree of anonymity -- if you run your own IdP, and are causing enough trouble to draw attention to yourself, they're likely to figure out that everyone using that IdP is you, no matter how many different identifiers you have it assert. Then you provide different identifiers to RP#1 and RP#2. Under OpenID 1.x this is rather cumbersome to do without custom tools in the user agent, but OpenID 2.0 enables IdP-driven identifier selection, which means your IdP can help you keep track of which identifier you provide to which RP. Also keep in mind that, even in the absence of any global user identifier scheme, the Internet presents other challenges to complete anonymity, e.g. your IP address. The level of technical understanding and aptitude required to avoid detection by those basic means will probably place it out of reach of most casual users. and, as an aside, for a fun read about just what can be done with your IP address in the hands of an outfit like the RIAA's legal team, see http://digitalmusic.weblogsinc.com/2006/08/07/the-riaa-vs-john-doe-a-laypersons-guide-to-filesharing-lawsui/ ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Delegation Proposal Amendment
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 checkid_* and id_res that defaults to openid.identity if it is missing. This field is the identifier by which the relying party knows the user. This is the identifier on which discovery was performed by the relying party. The name openid.rp_user_id is not the best, but it *is* very specific. Other suggestions welcome. Benefits This proposal retains the current behaviour in terms of who is responsible for discovery and verification. It makes the messages between the RP and IdP more explicit. It is completely backwards-compatible. IdP-driven identifier selection can now return a delegated identifier (if the user wishes to do so). Drawbacks = The IdP now has knowledge of the identifier that the user entered at the relying party. Discussion == I think there is general agreement that the protocol messages on the wire can lead to confusing results. I also think that it's easy to get the relying party implementation wrong because it has to keep track of state to ensure that the user gets the right identifier. I don't think that most relying parties will have a problem keeping state, but I think it's not a good idea to make proper behavior (using the right identifier) *depend* on the relying party's implementation of state storage. This proposal is similar in spirit to Martin's proposal, in that it acknowledges that delegation is not really a special case. The main difference is that (a) it is obvious from the protocol messages what is going on and (b) discovery is entirely unchanged. Related threads === Original proposal: http://openid.net/pipermail/specs/2006-September/02.html Brad's explanation of openid.delegate: http://openid.net/pipermail/specs/2006-October/000182.html Regarding the purpose of delegation: http://openid.net/pipermail/specs/2006-October/000170.html Martin's similar proposal: http://openid.net/pipermail/specs/2006-October/000216.html Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re[2]: [PROPOSAL] Separate Public Identifier from IdP Identifier
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 Regards, Chris Drake, =1id.com ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [PROPOSAL] Separate Public Identifier from IdP Identifier
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 openid:Token can be any URI. It's unclear to me whether you intended this to be a change from the current specification or not, but it is. Yadis discovery on URLs resolved from XRIs is considered redundant, as there's nothing about Yadis discovery that can't be done while resolving the XRI. Since Yadis uses the XRI resolution response format, you even get to use the same code. So was it your intention to add an extra layer to discovery here, or should the above section be reworded? ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: [PROPOSAL] Separate Public Identifier from IdP Identifier
+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 Identifier from IdP Identifier 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 openid:Token can be any URI. It's unclear to me whether you intended this to be a change from the current specification or not, but it is. Yadis discovery on URLs resolved from XRIs is considered redundant, as there's nothing about Yadis discovery that can't be done while resolving the XRI. Since Yadis uses the XRI resolution response format, you even get to use the same code. So was it your intention to add an extra layer to discovery here, or should the above section be reworded? ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Delegation Proposal Amendment
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 clouds we all have hanging over our heads ;) Do you mean literal Unix-style diffs or a human-readable set of changes to section numbers? Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: [PROPOSAL] bare response / bare request
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 Behalf Of Kevin Turner Sent: Friday, October 06, 2006 3:25 PM To: specs@openid.net Subject: Re: [PROPOSAL] bare response / bare request On Tue, 2006-10-03 at 19:42 -0700, Dick Hardt wrote: On 2-Oct-06, at 12:34 PM, Kevin Turner wrote: On Sat, 2006-09-30 at 20:09 -0400, Dick Hardt wrote: Motivating Use Case The IdP would like to allow the user to click a link on the IdP to login to an RP. This requires a bare response to be able to be sent. How will RPs that customarily use a request nonce treat this? There will not be a request nonce -- could have the IdP say none Implications of this: 1) RPs must always accept messages without a request nonce. 2) RPs must always accept messages at the same return_to URL. which also means 3) RPs must never put nonces or (other tokens that will become invalid) in the return_to, because if they did the IdP would not recognize it as a nonce and remove it. Are these things all okay? I'm not sure if they really break stuff, but that puts a lot more restrictions on the return_to than I really feel comfortable with. And quite possibly takes a lot of the utility out of request nonces. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: [PROPOSAL] bare response / bare request
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 both websites and IdPs would love it, is it okay if it's something that websites + IdPs can layer on top of the core? If some sites chose not to, and the IdP said login bookmark not available for this site, would that be okay? ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: [PROPOSAL] bare response / bare request
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 wrote: Okay Customer, if both websites and IdPs would love it, is it okay if it's something that websites + IdPs can layer on top of the core? If some sites chose not to, and the IdP said login bookmark not available for this site, would that be okay? I guess so. The test I would apply is: If the basic protocol makes it easy to layer on -- in a fashion that will be intereoperable by all RPs and IdPs that support it, then yes, it's okay to let it be layered on. If the basic protocol makes it tricky to implement, and thus not likely to be interoperable between the RPs and IdPs that want to do it, that's not okay. Does that help? =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Consolidated Delegate Proposal
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 Martin, please look this over and either make changes or comment as needed. It will be wonderful to finally close this issue. =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re[2]: [PROPOSAL] bare response / bare request
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 Customer, if both websites and IdPs would love it, is it okay if KT it's something that websites + IdPs can layer on top of the core? If KT some sites chose not to, and the IdP said login bookmark not available KT for this site, would that be okay? Technically - the only thing we need is a mechanism for the IdP to find the RPs OpenID bookmark entrance - a hidden field in the original login FORM should be sufficient: IdP can then save this URL in the users profile for them. Chris. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
