Re: [OpenID] Announce: OpenID Authentication Draft 12 (finally)
On 28-Aug-07, at 6:11 PM, Johnny Bufu wrote: On 27-Aug-07, at 7:05 PM, Peter Williams wrote: A. fragment identifiers on user input are to be removed. Do not remove the separator. Good thing we didn't call it final just yet. In my mind the separator was part of the fragment, but re-reading the URI RFC it clearly is not and you are right. So, RFC3986 says the # should be left as part of the URL? Apache logs indicate that user agents (or apache) behave otherwise. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Review of Yadis section in XRI Resolution 2.0 WD11
On 31-May-07, at 1:45 AM, Drummond Reed wrote: To make this new section easy to review, we've put it on the XRI TC wiki at: http://wiki.oasis-open.org/xri/XriCd02/XrdsDiscoveryFromHttpUris In Section 8.2: the value of the head element whose http-equiv attribute is X- XRDS-Location Should be meta element instead of head element to match with item 3 in the preceding list. I'd actually suggest writing item 3 in the list and that sentence like this for consistency: meta element with an http-equiv attribute equal to X-XRDS-Location or meta element with an http-equiv attribute value of X-XRDS-Location -Rowan ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: clarifying section 11.2 in draft 11 for HTML discovery?
On 25-May-07, at 11:18 AM, Peter Watkins wrote: It's too bad Yadis doesn't allow embedding the XRDS document in something like a META tag to avoid that second Yadis HTTP request If you send an Accept header that includes application/xrds+xml the OP can return the XRDS document on the first request. (From the Yadis 1.0 spec, Section 6.2.4) ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: encoding newlines in attribute values
On 18-Apr-07, at 9:47 PM, Johnny Bufu wrote: The core spec doesn't allow newline characters (\n) in any openid.* values. Currently, Attribute Exchange doesn't specify a way to encode newlines in attribute values. Every indirect OpenID message would seem to be already url-encoded by the browser, or server as post data .. so \n = %0A (i.e. application/x-www-form-urlencoded mime type) Do we need a pre-url-encode encoding, or can we rely on browsers to do the right thing... I suppose it's helpful to spell it out for non- browser agents that want to pass OpenID messages. If we want to define sending binary data in OpenID messages, maybe we should leverage multipart/form-data. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: PROPOSAL schema.openid.net for AX (and other extensions)
On 8-Apr-07, at 1:01 PM, Mark Wahl wrote: FYI if you are carrying attribuets in OpenID AX that are equivalent to LDAP attributes with attribute types being standardized in the IETF, then you could use our LDAP schema definition metadata. We have resolvable HTTP URIs for each of the widely-deployed attributes, such as givenName. For each LDAP attribute type definition in those RFCs, the schemat tool generated an OWL DatatypeProperty and a OWL Class. The URI of the OWL class generated from an LDAP attribute type is currently of the form http://www.ldap.com/1/schema/rfc.owl#AttributeType_OID That's not a bad list, although there are some attributes missing that I would have expected to see given all the sources used to compile the list. Birthday? State/Province, Country? Not to mention I clicked through about 4 different URLs and still couldn't figure out what the data for a particular attribute was supposed to look like :) .. everything is a owl#Class type? (I'm pretty new to this RDF stuff so maybe I just haven't learned to read the docs properly). The main difference I'm seeing is that AX metadata uses rdf:Description while you used owl:DatatypeProperty and owl:Class? And the rdf:type values for AX metadata use the w3 XMLSchema types... If some ID attributes were added to the elements, it would be easier to navigate the document, as the fragment would resolve to something useful in a browser. Would you consider filling in the rdfs:comment elements and adding openid:example elements? I think the elements unique to OpenID AX had been included on the idschemas wiki a while ago, so at least there was some work started there. -Rowan ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: PROPOSAL schema.openid.net for AX (and other extensions)
On 9-Apr-07, at 8:23 PM, Recordon, David wrote: Is there a list anywhere? I didn't find one in the documents and I think this list would benefit everyone in the conversation. I'm just curious as to the fields you're expecting an OP to implement. While at Standard, I ended up hosting our own schema so we would have a consistent set to work from and refer our partners to. It's based on attributes from an older revision of AX but the metadata should be pretty close to the existing format. The schema is posted here: http://idschema.standardinteractive.com/ I'm +1 on getting a set of attributes hosted on openid.net (maybe SREG properties as URI's plus some other common attributes), so implementors have something to sink their teeth into. -Rowan ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: PROPOSAL schema.openid.net for AX (and other extensions)
On 10-Apr-07, at 12:21 AM, Dick Hardt wrote: On 9-Apr-07, at 5:24 PM, Recordon, David wrote: Yes, I agree an upgrade path from SREG is needed. We could however do something as simple as http://openid.net/specs/openid-simple-registration- extension-1_0.html#nickname for the existing SREG fields. why not have a page that maps the existing SREG to the AX attributes we have already defined? why create yet-another set of attributes? Since SREG responses always return a (sub)set of predefined values, as long as we ensure all the SREG attributes are covered in the core list of AX attributes, they don't really need to be defined separately. And AX can perhaps have a SREG compatibility mode where it would return all the SREG values for a specific request. Since the main difference I'm seeing at the moment is that SREG doesn't specifically request each value it wants, except in openid.sreg.required and openid.sreg.optional. That, I would think, should be the upgrade path between the two. -Rowan ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: PROPOSAL schema.openid.net for AX (and other extensions)
On 10-Apr-07, at 9:39 AM, Josh Hoyt wrote: On 4/10/07, Rowan Kerr [EMAIL PROTECTED] wrote: Since the main difference I'm seeing at the moment is that SREG doesn't specifically request each value it wants, except in openid.sreg.required and openid.sreg.optional. Um, that is exactly how sreg requests each value that it wants. If it's in either of those lists, it's requested. But in AX, it must also be requested as a openid.ax.varname = URI in addition to the optional/required lists. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Server-to-server channel
On 3-Apr-07, at 9:18 AM, Anders Feder wrote: * The RP can't know the status of the information it is working with - it just have to assume that the attributes it has in store are up- to-date. The RP can send an update_url to the OP when it fetches the attributes, so it will get new values when the user changes them at the OP. * If an OP fails to update an attribute, the RP will never know - no fall-backs can be implemented. Fails when? On a Store request? * The OP must donate storage space to support the distribution of information to RP's it has no direct interest in. A malicious RP may even exploit this storage space for own purposes. Not sure I understand this. OP's normally would not have interest in any particular RPs the User has interest in RPs :) Although it is up to the individual OP to set rules about who it wants to talk to. * Attributes are not easily referenced to, say, sub-contractors of an RP. The model impose limits upon the complexity of the services that may be derived from it. You're free to publish the RDF for the attributes you support... then they are reference-able aren't they? -Rowan ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Attribute Exchange pre-draft 5
On 2-Apr-07, at 3:16 PM, Josh Hoyt wrote: What about attributes whose value could reasonably be an empty string? It would be reasonable to answer don't do that, I'm just curious how you expect this case to be handled. I'd say it's up to the RP to decide whether the data returned is valid for it's specific needs. -Rowan ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Attribute Exchange pre-draft 5
On 2-Apr-07, at 3:14 PM, Josh Hoyt wrote: On 3/26/07, Johnny Bufu [EMAIL PROTECTED] wrote: One feature we didn't figure out yet if its benefits would be worth the added complexity: - in a fetch response, distinguish between attributes that the user didn't *want* to release and the ones not supported by the OP. My intuition is that a server could advertise what attributes it supports rather than including this information in a user-specific response. So, -0.5 on this. If it does go in, I'd say -1 on making it REQUIRED. I suppose that (one or more) RDF file(s) could be returned as part of the AX discovery.. and the RDF's would have the attributes that are supported by the OP. I was just concerned about prompting a user multiple times for the same data, but if an RP can discover the supported attributes before requesting them, then that should cover it. -Rowan ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Attribute Exchange pre-draft 5
On 2-Apr-07, at 5:27 PM, Josh Hoyt wrote: I'm thinking about differentiating between an attribute that's not available and an attribute that *is* available, but its value is . I. e. difference between a null pointer, and a pointer to an empty string. That was part of why I had the idea of adding one or two extra response values... to know whether a user released the attribute (and whether it was supported by the OP). By looking at the namespace RDFs for the OP as you suggested, the RP should be able to decide whether the value is supported by the OP, then if it's blank AND supported, then the only thing the RP can't be sure about is whether or not the user released it. If the RP really needs a value, they can prompt the user for it after getting the AX response and it doesn't really matter whether the OP supports it or not. (Unless you're going to maybe try and Store it back to the OP later on). But prompting users twice for the same value (for lack of any way to know the cause of a blank value) might be an annoying experience. -Rowan ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Extensions key prefix
In all my time spent reading and implementing the OpenID Authn 2 spec, this particular detail escaped me. Johnny Bufu pointed it out to me the other day while we were going through some Attribute Exchange tests. http://openid.net/specs/openid-authentication-2_0-11.html#extensions To associate keys with a Type URI, establish an alias by adding a key prefixed with openid.ns. and ending with the alias text whose value is the Type URI. I never picked up on the fact that these aliases can be dynamic on a per-server or actually per-messsage basis, and assumed the key prefixes listed in the extension specs were what one could expect to see in a message. This affects all proposed extensions to OpenID 2.0... i.e. While the spec for Attribute Exchange uses openid.ax for its message keys, and Simple Reg 1.1 uses openid.sreg, in reality the keys received in a message are determined by whatever comes after the key openid.ns.* where the value is the URI of the extension putting data into those keys. So, openid.ns.ax = http://openid.net/srv/ax/1.0 implies openid.ax.required. But it could just as easily be openid.ns.foo = http://openid.net/srv/ ax/1.0 in which case, your sreg values would be in keys named openid.foo.* Is this clear to everyone else? It makes sense to me now, but I think it should be made more clear in the main spec, and perhaps the extension specs could move away from hardcoding the openid.ns.* and use an obvious placeholder string. -Rowan ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Extensions key prefix
On 13-Mar-07, at 6:23 PM, Drummond Reed wrote: If I understand you correctly here, what you are saying is that openid.ns.* prefixes work almost identically to XML namespace (xmlns) prefixes, i.e.: * the prefix is never globally defined by dynamically defined on a per-instance basis * thus you don't know what the prefix is in a specific OpenID message until you parse the message. Do I have that right? That's exactly it. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: DRAFT 11 - FINAL?
On 1/30/07, Josh Hoyt [EMAIL PROTECTED] wrote: *snip* While it is true that since the link relationship names changed, the openid2 is technically redundant, I think it is much clearer to everybody what is going on if the link relationship contains the version number. If the protocol version were to keep changing, I'd argue for a different solution. Sure, that's good enough reason. Since html discovery is not really the preferred method anyway, I don't think the openid2.* links should stand in the way of finalizing the spec :) -Rowan ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID Attribute Exchange 1.0 draft 4
On 1/9/07, Johnny Bufu [EMAIL PROTECTED] wrote: Please have a look at the latest (draft 4) OpenID Attribute Exchange 1.0 specification: http://openid.net/specs/openid-attribute-exchange-1_0-04.html This is looking good. I've been going over it updating my drupal modules to draft 4. The multiple values request is nice, and I'm sure we'll find a use for it at Standard shortly as we get a couple of our partners online with OpenID and AX. Of course, it's going to be a bit more difficult to get PHP behaving with the openid.type.stuff.1 but the limitations of one language shouldn't hold up the entire spec. Surely other people are intersted in using AX? Without that, I know I wouldn't have been implementing OpenID 2.. it would be nice to get some more dialog going about it. One thing that seems to be missing at the moment is how to treat a collection of values. eg: You fetch someone's name but want first, last, etc all together as one response. Maybe a ax.type.foo.join value would be useful? So then the discrete values of first and last name would be returned by the OP joined with whatever was specified in ax.type.foo.join. - Added note about the state of flux of the attribute types and metadata specifications Some sort of openid community standard for a base set of Metadata would be really helpful. Sure, Standard can go and publish our own spec that our partners know about but it will be of limited use when they would like to perform AX with a different OP. (If it'll be too arduous to acheive concensus at a community level, perhaps the equivalency protocol I've seen mentioned somewhere could be fleshed out and become the preferred method of supporting attributes across moultiple OP's). Who else on-list wants to be able to use a well-defined set of attributes? Speak up :) - Renamed openid.ax.fetch.alias to openid.ax.type.alias So now the only difference between a Fetch and Store is the existance of openid.ax.if_available and openid.ax.required and openid.ax.value... I'm not sure if that makes the messages harder to deal with because it's more opaque, or if it's nicer because the messages are now more standard. I suppose the main OpenID specs already rely on the absence of values rather than the presence or naming of, so maybe it's more in keeping with the general protocol. -Rowan -- Rowan Kerr Senior Web Programmer, Standard Interactive tel:+14169344451 xmpp:[EMAIL PROTECTED] http://standardinteractive.com/ ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: DRAFT 11 - FINAL?
On 1/31/07, Recordon, David [EMAIL PROTECTED] wrote: I'm happy changing it from AJAX. I think it was originally used since AJAX is a bit overloaded already and people normally understand the flashy non-reloading sort of thing when saying it. I suppose some people might, but for a developer (the kind of people most likely to end up implementing the spec), AJAX has a specific definition, and implies specific techniques that cannot actually be used with OpenID. Or perhaps I'm being too pedantic but there must be a more general term that wouldn't have the potential to cause such confusion. -Rowan ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: DRAFT 11 - FINAL?
The openid2.* links bug me a little.. but due to no openid.ns being defined in the 1.x protocol, maybe there is no other way to specify by HTML discovery that your OP is 2.0 capable. Would it be bad to have a openid.version link instead? Also, the spec mentions AJAX interactions, but I don't see how you can actually use AJAX with OpenID, since none of the responses are in XML format .. it relies entirely on GET or POST redirection, not to mention that you have to make cross-domain requests which XmlHttpRequest will not do without extra security privileges. (Or am I missing something?) -Rowan ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Business Scenarios
On 1/10/07, McGovern, James F (HTSC, IT) [EMAIL PROTECTED] wrote: I am looking for any generic whitepapers targeted at any vertical that outline a business scenario (not the usual consumer-orientation) where user-centric identity has either been deployed or at least discussed. I don't have a whitepaper (yet?), but we're using openid for listener club information and working with our 3rd party service providers to make their services openid-enabled so they can access one common set of data. -Rowan -- Rowan Kerr Senior Web Programmer, Standard Interactive tel:+14169344451 xmpp:[EMAIL PROTECTED] http://standardinteractive.com/ ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Attribute Exchange Schema site
On 1/5/07, Dick Hardt [EMAIL PROTECTED] wrote: The Attribute Type model is such that anyone with a domain can define new attributes. No need for central control. We created a set of what we thought were common attributes, but that does not mean anyone has to use them. Being able to define domain-specific attributes is great. (Made use of that a while ago). Although a solid base set of attributes is important so RP's don't have to learn a new attribute for First Name every time they interact with a different OP. Unless the domain of the attribute is always replaced by the domain of the OP, and only the path matters... (not quite as nice as having one official place for a core set of attributes but better than a complete free for all). -Rowan ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Attribute Exchange Schema site
On 1/3/07, Dick Hardt [EMAIL PROTECTED] wrote: Our proposal was to have the schemas for OpenID hosted at schema.openid.net. Some people expressed concerns about having them be on openid.net. Do you have any suggestions? Anyone else have an opinion? Does anyone care? ;-) Being part of the OpenID specs, it would make sense to me to have them hosted under the OpenID domain. (While a centralized, shared list of properties would be great in the long run, who knows how long it could take to get agreement from something like idcommons). Really, I don't particularly mind if they're even hosted anywhere at the moment as long as the list of properties is well defined. We've implemented a OP at my.standardradio.com that supports OpenID 2 and the Draft 1 version of AX properties, and I'm in the middle of writing documentation for our 3rd party clients on how to work with our site so I was hoping to be able to update it to the latest version of the spec before sending out documentation that is already behind the times. Failing a solid list of AX Draft 2 properties, is the Draft 1 documentation still online somewhere? There is a schema effort over at http://idschemas.idcommons.net/ -- but discussion over there has been minimal to date, but perhaps this can jump start things ... I'll check that out, I remember when it was announced but never followed up on how any of that was progressing. btw: nice to see a fellow Canuck on the list! Glad to be here! I've been on for a while but not had cause to jump into the discussions much. Too busy implementing... :) -Rowan ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Attribute Exchange Schema site
I was going through Draft 2 of the Attribute Types spec, and noticed that the referenced site for default OpenID types is not set up.. http://openid.net/specs/openid-attribute-types-1_0-02.html -- http://schema.openid.net/ I have OpenID code working with Draft 1 of the spec, and would like to update it for Draft 2 if someone can make the default types site and accompanying XML docs available. Thanks, -Rowan -- Rowan Kerr Senior Web Programmer, Standard Interactive tel:+14169344451 xmpp:[EMAIL PROTECTED] http://standardinteractive.com/ ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: IdP's Advertising Both http and https
On Wed, 2006-11-08 at 00:42 -0800, Dick Hardt wrote: -Original Message- From: Recordon, David But the security warnings will still exist: - RP redirects me to http on IdP - IdP redirects me to https on IdP for login page (warning) no warning on GET redirects If GET is going to be an acceptable method for responses, the spec should be updated. Section 5.2.1. HTTP Redirect states: This method is deprecated as of OpenID Authentication version 2.0 though is still required for implementation to aide in backwards compatibility. Yes/no? -Rowan ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Making identities persistent?
On Wed, 2006-11-01 at 11:33 -0500, John Kemp wrote: I think you need the ability for a user to change his identifier at the RP (as George notes below) and also at the IdP. Isn't this was already covered in the spec? You accomplish this by creating an HTML page on some website you control with a http-equiv meta tag in it that points to your IdP. Then you use your own url as your Identity, even though ultimately the data is pulled from the IdP. So if you ever want to change IdP's you simply update your html page with the new server. And your Identifier never needs to change. In addition, it should be possible for the IdP to providing OpenID forwarding if the user leaves for another IdP (perhaps the user will even pay for a forwarding service?) Is there anything against an IdP implementing the delegate feature to forward to a different server? -Rowan ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
