Re: [OpenID] FW: PROPOSAL: An Extension to transform an EMail Address to an OpenId URL
On 2/9/07, David Fuelling <[EMAIL PROTECTED]> wrote: > I appreciate any and all feedback! For what it's worth I think that this is excellent. A couple of suggestions: 1) You probably should take a look at the URI Template spec [1]. These guys have done a lot of the work for you. The spec is still in active development and has been blogged about by the author [2], I think that they are about to release a new version with some updates. 2) Why map the e-mail address to an openid url, which then has to be further resolved to a Yadis document? Why not, instead, map straight to a yadis doc and make e-mails full fledged openids. An openid is nothing more than a URI that can be resolved to a Yadis doc. mailto:[EMAIL PROTECTED] is a perfectly valid URI and you have demonstrated a pretty simple way to map it to a yadis doc. Rob [1]http://www.ietf.org/internet-drafts/draft-gregorio-uritemplate-00.txt [2]http://bitworking.org/news/URI_Templates ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
attribute exchange draft 4 review
Hello list! While reviewing our AX implementation, I came across a case where the spec is not clear enough: openid.ax.required The value of this parameter is an attribute alias, or a list of aliases corresponding to the URIs defined by "openid.ax.type." parameters. The OpenID Provider MUST provide the identity information specified in this parameter or return an error condition. The error condition that the OP is supposed to return is not fully specified. We mention in the overview section that standard OpenID error messages should be used, but those would indicate a core / authentication failure. My question is how would you, as an implementer on the RP side, prefer to be notified that the user / OP were not willing / able to supply a required attribute? Thanks, Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Proposal: An anti-phishing compromise
I chatted with Avery about this today. URIs for specific auth methods as well as ones for general seems to be the flexible approach. Per Kim's laws, the method of auth may not be needed, so is extra disclosure On 8-Feb-07, at 11:38 PM, Recordon, David wrote: > Maybe laws are meant to be broken. I don't see why a RP knowing > that I > used a token as a second factor is a bad thing. If nothing else, the > technology should support the OP providing that information and the > OP's > implementation can let me as the user decide if I want to. Just like > the trust request, it isn't mandated by the spec but every > worthwhile OP > does it. > > My $0.02. > > --David > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Dick Hardt > Sent: Sunday, February 04, 2007 11:42 PM > To: Granqvist, Hans > Cc: OpenID specs list > Subject: Re: Proposal: An anti-phishing compromise > > > On 1-Feb-07, at 2:36 PM, Granqvist, Hans wrote: >>> Add a single, required, boolean field to the authentication response >>> that specifies whether or not the method the OP used to authenticate >>> the user is phishable. The specification will have to provide >>> guidelines on what properties an authentication mechanism needs to >>> have in order to be "non-phishable." The field is just meant to >>> indicate that the authentication mechanism that was used is not a >>> standard "secret entered into a Web form." >> >> The receiver should decide what is 'non-phishable', not the >> sender, so > >> it would be better if the OP just states what mechanism was used, >> perhaps. > > Per Kim's laws, how I authenticate to my OP is none of the RP's > business. > That I authenticated in a phishing resistant manner is. > > ie. we want the OP to make the statement that it followed certain > anti-phishing guidelines. > > There is no certainty that the OP followed them, but the RP and user > have recourse against an OP if the OP stated that it did follow the > anti-phishing guidelines. > > -- Dick > ___ > 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: An anti-phishing compromise
Recordon, David wrote: > I agree that things like age should be in an extension, though I think > this single piece of data is useful in the core protocol. I'm sure the > exact definition of phishing resistant will come back to bite us in > sometime in the future, but lets deal with it then instead of not adding > anything now. I really like the idea that there be one thing in the > core spec which reaches out to each extension. > I propose: openid.make_it_work=1 ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
