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 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#ni ckname for the existing SREG fields. by making this a fragment, you force a requirement that Mark's tool has to be able to dig into a document and find the anchor as opposed to the attribute being self contained -- a complication I am not sure we want to deal with at this point in the meta-data 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? Myself, I think a developer would like to look in ONE place to find all the common web related attributes she will likely need so that she can build her app and not have to go looking across a dozen different sources to write some code. There will definitely be attributes that are for specific communities, so the developer will need to look in a few places, but why make it harder then it needs to be at this point in time? A number of people have spoken up to vote +1 to use schema.openid.net. Given that you have the magic wand David, are you going to let the community progress or do we have to keep arguing with you until one party wears out and gives up? -- Dick ___ 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: PROPOSAL schema.openid.net for AX (and other extensions)
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#ni ckname for the existing SREG fields. Dick wrote: by making this a fragment, you force a requirement that Mark's tool has to be able to dig into a document and find the anchor as opposed to the attribute being self contained -- a complication I am not sure we want to deal with at this point in the meta-data 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? Myself, I think a developer would like to look in ONE place to find all the common web related attributes she will likely need so that she can build her app and not have to go looking across a dozen different sources to write some code. There will definitely be attributes that are for specific communities, so the developer will need to look in a few places, but why make it harder then it needs to be at this point in time? A number of people have spoken up to vote +1 to use schema.openid.net. Given that you have the magic wand David, are you going to let the community progress or do we have to keep arguing with you until one party wears out and gives up? I haven't spoken up yet, but I feel strongly that creating YAAD (Yet Another Attribute Dictionary) for OpenID is a bad idea. OpenID is a wonderful force for driving towards attribute dictionary convergence, but that is not the focus of OpenID. It is however the direct focus of the Identity Commons Identity Schemas Working Group (site: http://idschemas.idcommons.net/, charter: http://wiki.idcommons.net/moin.cgi/IdentitySchemasCharter). Since the problem of attribute interop is larger than OpenID, I strongly recommend that those of us in the OpenID community that want to see this problem solved join the idschemas mailing list (http://mail.idcommons.net/cgi-bin/mailman/listinfo/idschemas) and work out the attribute dictionary (complete with synonyms) there. That way OpenID, CardSpace, XDI, and any technology that needs to move around standard profile data will have half a prayer of actually doing it interoperably. =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: PROPOSAL schema.openid.net for AX (and other extensions)
Hey Brian. Just to clarify, I don't think there is disagreement that this should be discussed here. Rather the question is if discussion should be around creating a new schema on openid.net or rather looking at using an exisiting one such as ldap.com that Mark posted about? Ie, discussion location aside, do you believe the OpenID project should be creating a new schema of its own? --David -Original Message- From: Brian Hernacki [mailto:[EMAIL PROTECTED] Sent: Monday, April 09, 2007 09:48 AM Pacific Standard Time To: OpenID specs list Subject:Re: PROPOSAL schema.openid.net for AX (and other extensions) On 4/6/07 6:07 PM, Dick Hardt [EMAIL PROTECTED] wrote: If anyone implementing would like to do something different, then I'd welcome additional discussion, otherwise I think we should be able to move forward with the proposal. For what it's worth, as an implementer... I think it makes sense to come to agreement within the OpenID community and get something working first. While I appreciate the issues involved with having multiple protocols and attribute definitions, I worry that if this becomes coupled to other efforts it would cause delays. Better to at least come to that table with a sound version of what we think works. Given that, discussing it here (openid.net) seems natural. --brian ___ 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 schema.openid.net for AX (and other extensions)
The short answer is yes. The longer answer is that while in a perfect world we¹d have some great common schema we could just use, I¹m not aware of any today. I worry that attempting to navigate the existing schema efforts would introduce significant delay. Also, approaching compatibility with a well thought out ³open id schema² would likely make any such discussion easier. Clearly, any schema effort should consider existing models of use, compatibility with similar common technologies (e.g. Cardspace) and support for future change. --brian On 4/9/07 10:01 AM, Recordon, David [EMAIL PROTECTED] wrote: Hey Brian. Just to clarify, I don't think there is disagreement that this should be discussed here. Rather the question is if discussion should be around creating a new schema on openid.net or rather looking at using an exisiting one such as ldap.com that Mark posted about? Ie, discussion location aside, do you believe the OpenID project should be creating a new schema of its own? ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: PROPOSAL schema.openid.net for AX (and other extensions)
Are you really proposing that we should redefine First Name again? Probably badly, as it has been done 1 times before? (because previous experience in, say, representing the name structure in non- western societies, typically doesn't get reused when things get redefined?) My point, of course, is not about First Name. What about simply pointing to established definitions where they exist and have some market traction, and only inventing new stuff where it doesn't exist? On Apr 9, 2007, at 10:39, Brian Hernacki wrote: The short answer is yes. The longer answer is that while in a perfect world we’d have some great common schema we could just use, I’m not aware of any today. I worry that attempting to navigate the existing schema efforts would introduce significant delay. Also, approaching compatibility with a well thought out “open id schema” would likely make any such discussion easier. Clearly, any schema effort should consider existing models of use, compatibility with similar common technologies (e.g. Cardspace) and support for future change. --brian On 4/9/07 10:01 AM, Recordon, David [EMAIL PROTECTED] wrote: Hey Brian. Just to clarify, I don't think there is disagreement that this should be discussed here. Rather the question is if discussion should be around creating a new schema on openid.net or rather looking at using an exisiting one such as ldap.com that Mark posted about? Ie, discussion location aside, do you believe the OpenID project should be creating a new schema of its own? ___ 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 schema.openid.net for AX (and other extensions)
Well, I'll stick my neck out here for my first post since AX drives most of my interest in OpenID (aside from being an identity junkie in general). As an implementor - there would be extremely positive benefits from having a base set of attributes defined and available @ schema.openid.net . I agree that the people most interested right now are the OpenID community implementors and it makes sense (to me) for openid.net to offer something - even just as a 'getting started point'. The problem is, if we wait for something neutral / 3rd party, the waiting game could take forever - and get drawn up in debates on how to most properly define First Name. To quote a member of this list, simple and open wins. Let's keep it simple. The beauty of AX that we can declare attribute equivalence, as well as RPs are free to use more proper attributes long term. What we need now (from my point of view) is a base set that we can work against to build momentum behind AX (building on the momentum already behind OpenID). So, +1 for going ahead with schema.openid.net My $0.02CAD. On 4/9/07 1:58 PM, Johannes Ernst wrote: Are you really proposing that we should redefine First Name again? Probably badly, as it has been done 1 times before? (because previous experience in, say, representing the name structure in non-western societies, typically doesn't get reused when things get redefined?) My point, of course, is not about First Name. What about simply pointing to established definitions where they exist and have some market traction, and only inventing new stuff where it doesn't exist? On Apr 9, 2007, at 10:39, Brian Hernacki wrote: The short answer is yes. The longer answer is that while in a perfect world we’d have some great common schema we could just use, I’m not aware of any today. I worry that attempting to navigate the existing schema efforts would introduce significant delay. Also, approaching compatibility with a well thought out “open id schema” would likely make any such discussion easier. Clearly, any schema effort should consider existing models of use, compatibility with similar common technologies (e.g. Cardspace) and support for future change. --brian On 4/9/07 10:01 AM, Recordon, David [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hey Brian. Just to clarify, I don't think there is disagreement that this should be discussed here. Rather the question is if discussion should be around creating a new schema on openid.net or rather looking at using an exisiting one such as ldap.com that Mark posted about? Ie, discussion location aside, do you believe the OpenID project should be creating a new schema of its own? ___ specs mailing list specs@openid.net mailto:specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs -- James Walker :: http://walkah.net/ :: xmpp:[EMAIL PROTECTED] ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: PROPOSAL schema.openid.net for AX (and other extensions)
On 4/9/07 3:55 PM, Martin Atkins wrote: James Walker wrote: As an implementor - there would be extremely positive benefits from having a base set of attributes defined and available @ schema.openid.net . I agree that the people most interested right now are the OpenID community implementors and it makes sense (to me) for openid.net to offer something - even just as a 'getting started point'. [snip] What we need now (from my point of view) is a base set that we can work against to build momentum behind AX (building on the momentum already behind OpenID). If our goal is to not reinvent the wheel, then let's just identify some AX mappings for the existing SREG fields, thus killing two birds with one stone: people migrating from SREG get some fields that offer one-to-one mappings, and these fields can be defined just by referencing the existing SREG specification so we avoid having to define anything. SREG seems to be working well in the common case, so it seems like a reasonable place to start. I agree it's an excellent place to start - upgrade path + as you point out it's working well in several cases today. -- James Walker :: http://walkah.net/ :: xmpp:[EMAIL PROTECTED] ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: PROPOSAL schema.openid.net for AX (and other extensions)
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#ni ckname for the existing SREG fields. For new fields, is there a reason we can't use the ldap.com URLs Mark posted as a starting point? I know Dick said they didn't cover all the needed attributes, but would it be good enough to start with and then expand from there possibly on schema.openid.net? Dick, do you have a list of attributes you see as needed for the first implementations of AX (I couldn't find one in the current AX specs though I fully admit I may be looking in the wrong place)? --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Walker Sent: Monday, April 09, 2007 1:10 PM To: Martin Atkins Cc: OpenID specs list Subject: Re: PROPOSAL schema.openid.net for AX (and other extensions) On 4/9/07 3:55 PM, Martin Atkins wrote: James Walker wrote: As an implementor - there would be extremely positive benefits from having a base set of attributes defined and available @ schema.openid.net . I agree that the people most interested right now are the OpenID community implementors and it makes sense (to me) for openid.net to offer something - even just as a 'getting started point'. [snip] What we need now (from my point of view) is a base set that we can work against to build momentum behind AX (building on the momentum already behind OpenID). If our goal is to not reinvent the wheel, then let's just identify some AX mappings for the existing SREG fields, thus killing two birds with one stone: people migrating from SREG get some fields that offer one-to-one mappings, and these fields can be defined just by referencing the existing SREG specification so we avoid having to define anything. SREG seems to be working well in the common case, so it seems like a reasonable place to start. I agree it's an excellent place to start - upgrade path + as you point out it's working well in several cases today. -- James Walker :: http://walkah.net/ :: xmpp:[EMAIL PROTECTED] ___ 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 schema.openid.net for AX (and other extensions)
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. --David -Original Message- From: Dick Hardt [mailto:[EMAIL PROTECTED] Sent: Monday, April 09, 2007 07:12 PM Pacific Standard Time To: Recordon, David Cc: James Walker; Martin Atkins; Mark Wahl; OpenID specs list Subject:Re: PROPOSAL schema.openid.net for AX (and other extensions) On 9-Apr-07, at 5:24 PM, Recordon, David wrote: For new fields, is there a reason we can't use the ldap.com URLs Mark posted as a starting point? I know Dick said they didn't cover all the needed attributes, but would it be good enough to start with and then expand from there possibly on schema.openid.net? Dick, do you have a list of attributes you see as needed for the first implementations of AX (I couldn't find one in the current AX specs though I fully admit I may be looking in the wrong place)? There are many, many attributes that we are using in AX that are not in LDAP, or don't have the granularity. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: PROPOSAL schema.openid.net for AX (and other extensions)
The list is a set of xml files that we wanted to post on schema.openid.net so that everyone could see them per the proposed draft. Each attribute has a chunk of meta data around it. ( the files are all viewable and browsable as well as being machine readable) A good OP would dynamically add new attributes as they become available as opposed to statically coding a set. If you would be kind enough to let us set up schema.openid.net, then we could more easily show everyone. -- Dick 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. --David -Original Message- From: Dick Hardt [mailto:[EMAIL PROTECTED] Sent: Monday, April 09, 2007 07:12 PM Pacific Standard Time To: Recordon, David Cc: James Walker; Martin Atkins; Mark Wahl; OpenID specs list Subject:Re: PROPOSAL schema.openid.net for AX (and other extensions) On 9-Apr-07, at 5:24 PM, Recordon, David wrote: For new fields, is there a reason we can't use the ldap.com URLs Mark posted as a starting point? I know Dick said they didn't cover all the needed attributes, but would it be good enough to start with and then expand from there possibly on schema.openid.net? Dick, do you have a list of attributes you see as needed for the first implementations of AX (I couldn't find one in the current AX specs though I fully admit I may be looking in the wrong place)? There are many, many attributes that we are using in AX that are not in LDAP, or don't have the granularity. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: PROPOSAL schema.openid.net for AX (and other extensions)
Hi Mark The URL mapping of LDAP attributes below looks pretty useful. Some of those overlap with attributes we defined for AX, but many of the attributes in AX are not defined, or don't have the same granularity. Given that LDAP attributes were defined per the needs of enterprise, and AX attributes reflect the attributes commonly requested on public web forms, this is to be expected. With a goal of making it easy for people to use AX, I'd like to have a list of common web oriented attributes readily available for developers to work with. What do you think of using the equivalence mechanisms to map common attributes between the two sets, but allowing the two sets to maintain their focus on solving the problems for their separate communities? ... or do you think we should try and come up with a master set of core attributes? -- Dick On 8-Apr-07, at 1:01 PM, Mark Wahl wrote: Dick Hardt wrote: If there was something out there already, I would propose we used it. There is not. Just like the SAML crowd has accused the OpenID crowd of reinventing an identity protocol (AKA reinventing the wheel) -- the AX proposal has some unique concepts that people like Paul and Mark think are quite innovative. Other schemas don't support them. I have cc'ed Paul and Mark in case they can point to some new work that we can take advantage of today. 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. Background: In order to get some test data for developing our Schemat 'reference implementation' of identity metasystem schema management tools, we (Informed Control) have been generating metadata for the LDAP/X.500 schema definitions that are in IETF RFCs. For our first cut, we took the definitions from these RFCs: 2079 Definition of an X.500 Attribute Type and an Object Class to Hold Uniform Resource Identifiers (URIs). M. Smith. January 1997. (Format: TXT=8757 bytes) (Status: PROPOSED STANDARD) 2798 Definition of the inetOrgPerson LDAP Object Class. M. Smith. April 2000. (Format: TXT=32929 bytes) (Updated by RFC3698, RFC4519, RFC4524) (Status: INFORMATIONAL) 4512 Lightweight Directory Access Protocol (LDAP): Directory Information Models. K. Zeilenga, Ed.. June 2006. (Format: TXT=108377 bytes) (Obsoletes RFC2251, RFC2252, RFC2256, RFC3674) (Status: PROPOSED STANDARD) 4519 Lightweight Directory Access Protocol (LDAP): Schema for User Applications. A. Sciberras, Ed.. June 2006. (Format: TXT=64996 bytes) (Obsoletes RFC2256) (Updates RFC2247, RFC2798, RFC2377) (Status: PROPOSED STANDARD) 4524 COSINE LDAP/X.500 Schema. K. Zeilenga, Ed.. June 2006. (Format: TXT=11245 bytes) (Obsoletes RFC1274) (Updates RFC2247, RFC2798) (Status: PROPOSED STANDARD) and generated RDF/XML files with metadata translated into OWL from the LDAP representation. (We picked those RFCs since there was already a change control and standardization process for them, they represented rough concensus as a minimum interoperable set of definitions, the objectclasses in them are stable, these schemas are widely supported by many LDAP servers as a native schema, and contained the schema used in example LDIF/DSML files. There are certainly other non-obsolete RFCs containing LDAP schemas, which we'll address later as there's interest; I don't think there's any technical limitations that would have prevented us from extracting metadata from them). 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 where is the number of the RFC, and OID is the string encoding of the attribute's object identifier. (We chose to use the OID in the URI, rather than a string, since LDAP allows an attribute to have multiple string names, and does not have a 'primary' string name. Having to equivalentClass between multiple Classes for a single LDAP attribute type definition seemed worse than having one Class with an identifier already known to be unique). We chose the ldap.com domain name as we have it :-) and these are LDAP-developed definitions; I'm not wedded to the ldap.com domain name, and considered two alternatives: - using an 'oid' URI form This would be a suitable alternative URI, however, this would introduce a dependency on a oid URN namespace resolver, which isn't yet operational. - using an ietf.org or iana.org domain name This would be our preferred long-term strategy, as the
Re: PROPOSAL schema.openid.net for AX (and other extensions)
If there was something out there already, I would propose we used it. There is not. Just like the SAML crowd has accused the OpenID crowd of reinventing an identity protocol (AKA reinventing the wheel) -- the AX proposal has some unique concepts that people like Paul and Mark think are quite innovative. Other schemas don't support them. I have cc'ed Paul and Mark in case they can point to some new work that we can take advantage of today. Other responses inserted: On 6-Apr-07, at 11:49 AM, Recordon, David wrote: As I've stated in the past, I have no problem with using schema.openid.net to define attributes such as the authoritative URI for an OpenID URL, i-name, etc. I do have a problem with using this namespace to define an attribute such as a First Name. I do not feel that this community should be dealing with all of the issues such as First Name vs. Given Name, as that is not where the expertise is, let alone it has been done in the past. I also strongly believe that due to the number of other definitions of these attributes, either we as a community should decide to use one of them or work with a project such as ID Schemas to create a set of URIs not tied to the OpenID project that solves both our needs and the needs of others. I do not particularly care where this work would happen and as I've said in the past, I'd be fine with someone just buying a domain to do the work to preserve the speed for getting this bootstrapped while not tying it to OpenID. If really don't care, then you should not care if it is happening in OpenID then. First Name: - http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname This URL could be used. To date they have not made these self describing. Who knows what this is? The AX proposal is to make the URLs describing. This makes it easier for programmers to know what it is they are working with. - http://xmlns.com/foaf/0.1/firstName - http://xmlns.com/foaf/0.1/givenname Both of these are elements in a larger XML document. This is not the model of AX. - http://en.wikipedia.org/wiki/First_name While intriguing to have wikiality define terms, this is not practical since the definition needs to be static or code will break I'm sure if Paul Trevithick or Mark Whal join this conversation they'd be able to highlight even more URI definitions of a First Name than I was in a cursory search. This also isn't including all of the work done for things such as LDAP, vCard, or others listed at http://idschemas.idcommons.net/moin.cgi/List_Of_Schemas in defining what these schema attributes are and mean. Most other work has created closed schemas. The AX proposal is an open schema where anyone can define a new attribute and each one is self describing. If we want to create URLs for attributes from an existing schema (such as LDAP or vCard) since easy URLs do not currently exist, then that is one thing. Creating an entirely new definition of commonly used attributes IMHO is unacceptable. People keep doing it for a variety of reasons. People keep inventing new programming languages. We should be reusing anything that we can, not inventing something new especially given the complexity of this particular task. The task has largely been done. Still need to finalize the meta-data file format. I'm not sure what more I can do to urge this community to not reinvent the wheel in this area. See comment at top. AX does not need a wheel. AX needs a wing. Wings don't exist right now. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: PROPOSAL schema.openid.net for AX (and other extensions)
I think it is great that there is new and innovative work in what you've been doing. I would also think that it would benefit the entire user-centric (and even non-user-centric) community to take advantage of this work regardless of the technology. By having it rooted on openid.net, I think there will be aversion to doing so and other communities will rather jump to the conclusion that the OpenID community is yet again reinventing the wheel by defining common core attributes. This is what I want to avoid. By doing this in a neutral location, not tied to a specific identity technology, it removes this concern as well as does more good for the entire ecosystem. If the ID Schemas project is not the right place to do it, then I see no reason not to create one; I would be happy to front the cost of a domain name if needed. I'd also think this would be something worth discussing at IIW when the entire community comes together. I would really like to see this be something that can be used by OpenID, CardSpace, Higgins, SAML, etc. --David -Original Message- From: Dick Hardt [mailto:[EMAIL PROTECTED] Sent: Friday, April 06, 2007 1:07 PM To: Recordon, David Cc: OpenID specs list; Paul Trevithick; Mark Wahl Subject: Re: PROPOSAL schema.openid.net for AX (and other extensions) If there was something out there already, I would propose we used it. There is not. Just like the SAML crowd has accused the OpenID crowd of reinventing an identity protocol (AKA reinventing the wheel) -- the AX proposal has some unique concepts that people like Paul and Mark think are quite innovative. Other schemas don't support them. I have cc'ed Paul and Mark in case they can point to some new work that we can take advantage of today. Other responses inserted: On 6-Apr-07, at 11:49 AM, Recordon, David wrote: As I've stated in the past, I have no problem with using schema.openid.net to define attributes such as the authoritative URI for an OpenID URL, i-name, etc. I do have a problem with using this namespace to define an attribute such as a First Name. I do not feel that this community should be dealing with all of the issues such as First Name vs. Given Name, as that is not where the expertise is, let alone it has been done in the past. I also strongly believe that due to the number of other definitions of these attributes, either we as a community should decide to use one of them or work with a project such as ID Schemas to create a set of URIs not tied to the OpenID project that solves both our needs and the needs of others. I do not particularly care where this work would happen and as I've said in the past, I'd be fine with someone just buying a domain to do the work to preserve the speed for getting this bootstrapped while not tying it to OpenID. If really don't care, then you should not care if it is happening in OpenID then. First Name: - http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname This URL could be used. To date they have not made these self describing. Who knows what this is? The AX proposal is to make the URLs describing. This makes it easier for programmers to know what it is they are working with. - http://xmlns.com/foaf/0.1/firstName - http://xmlns.com/foaf/0.1/givenname Both of these are elements in a larger XML document. This is not the model of AX. - http://en.wikipedia.org/wiki/First_name While intriguing to have wikiality define terms, this is not practical since the definition needs to be static or code will break I'm sure if Paul Trevithick or Mark Whal join this conversation they'd be able to highlight even more URI definitions of a First Name than I was in a cursory search. This also isn't including all of the work done for things such as LDAP, vCard, or others listed at http://idschemas.idcommons.net/moin.cgi/List_Of_Schemas in defining what these schema attributes are and mean. Most other work has created closed schemas. The AX proposal is an open schema where anyone can define a new attribute and each one is self describing. If we want to create URLs for attributes from an existing schema (such as LDAP or vCard) since easy URLs do not currently exist, then that is one thing. Creating an entirely new definition of commonly used attributes IMHO is unacceptable. People keep doing it for a variety of reasons. People keep inventing new programming languages. We should be reusing anything that we can, not inventing something new especially given the complexity of this particular task. The task has largely been done. Still need to finalize the meta-data file format. I'm not sure what more I can do to urge this community to not reinvent the wheel in this area. See comment at top. AX does not need a wheel. AX needs a wing. Wings don't exist right now. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman
Re: PROPOSAL schema.openid.net for AX (and other extensions)
The work is not rooted in openid.net. We are starting there. We can easily point those definitions somewhere else later, but we need somewhere to start. Given that the community that cares today is in OpenID, and the domain the community has is openid.net, it would make sense to use that domain. A different domain is going to have the same issues of control. I would expect that other members of the community would have concerns if it was rooted at say sxip.org. Happy to have further discussions at IIW, but don't see why the work here should wait until then. Other communities may or may not want to take advantage of what we are doing, and it will be easier for them to understand what we have if we have working code then just more talk about it. To take a step back, the people to decide this should be the people that are doing implementations. Would you clarify David if *you* are implementing, or just sharing your opinion? If anyone implementing would like to do something different, then I'd welcome additional discussion, otherwise I think we should be able to move forward with the proposal. -- Dick On 6-Apr-07, at 2:03 PM, Recordon, David wrote: I think it is great that there is new and innovative work in what you've been doing. I would also think that it would benefit the entire user-centric (and even non-user-centric) community to take advantage of this work regardless of the technology. By having it rooted on openid.net, I think there will be aversion to doing so and other communities will rather jump to the conclusion that the OpenID community is yet again reinventing the wheel by defining common core attributes. This is what I want to avoid. By doing this in a neutral location, not tied to a specific identity technology, it removes this concern as well as does more good for the entire ecosystem. If the ID Schemas project is not the right place to do it, then I see no reason not to create one; I would be happy to front the cost of a domain name if needed. I'd also think this would be something worth discussing at IIW when the entire community comes together. I would really like to see this be something that can be used by OpenID, CardSpace, Higgins, SAML, etc. --David -Original Message- From: Dick Hardt [mailto:[EMAIL PROTECTED] Sent: Friday, April 06, 2007 1:07 PM To: Recordon, David Cc: OpenID specs list; Paul Trevithick; Mark Wahl Subject: Re: PROPOSAL schema.openid.net for AX (and other extensions) If there was something out there already, I would propose we used it. There is not. Just like the SAML crowd has accused the OpenID crowd of reinventing an identity protocol (AKA reinventing the wheel) -- the AX proposal has some unique concepts that people like Paul and Mark think are quite innovative. Other schemas don't support them. I have cc'ed Paul and Mark in case they can point to some new work that we can take advantage of today. Other responses inserted: On 6-Apr-07, at 11:49 AM, Recordon, David wrote: As I've stated in the past, I have no problem with using schema.openid.net to define attributes such as the authoritative URI for an OpenID URL, i-name, etc. I do have a problem with using this namespace to define an attribute such as a First Name. I do not feel that this community should be dealing with all of the issues such as First Name vs. Given Name, as that is not where the expertise is, let alone it has been done in the past. I also strongly believe that due to the number of other definitions of these attributes, either we as a community should decide to use one of them or work with a project such as ID Schemas to create a set of URIs not tied to the OpenID project that solves both our needs and the needs of others. I do not particularly care where this work would happen and as I've said in the past, I'd be fine with someone just buying a domain to do the work to preserve the speed for getting this bootstrapped while not tying it to OpenID. If really don't care, then you should not care if it is happening in OpenID then. First Name: - http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname This URL could be used. To date they have not made these self describing. Who knows what this is? The AX proposal is to make the URLs describing. This makes it easier for programmers to know what it is they are working with. - http://xmlns.com/foaf/0.1/firstName - http://xmlns.com/foaf/0.1/givenname Both of these are elements in a larger XML document. This is not the model of AX. - http://en.wikipedia.org/wiki/First_name While intriguing to have wikiality define terms, this is not practical since the definition needs to be static or code will break I'm sure if Paul Trevithick or Mark Whal join this conversation they'd be able to highlight even more URI definitions of a First Name than I was in a cursory search. This also isn't
RE: PROPOSAL schema.openid.net for AX (and other extensions)
You also could go buy idschemas.org and start there, to be migrated later if need be. I don't really care who owns the domain since the wider community will hold the owner to do the right thing, though I'd imagine donating it to Identity Commons to hold would be an easy thing to do. Yes, VeriSign is activly developing OpenID 2.0 code in Java (http://code.google.com/p/joid/) and evaluating if/when we'll be implementing Attribute Exchange alongside Simple Registration. --David -Original Message- From: Dick Hardt [mailto:[EMAIL PROTECTED] Sent: Friday, April 06, 2007 6:07 PM To: Recordon, David Cc: OpenID specs list; Paul Trevithick; Mark Wahl Subject: Re: PROPOSAL schema.openid.net for AX (and other extensions) The work is not rooted in openid.net. We are starting there. We can easily point those definitions somewhere else later, but we need somewhere to start. Given that the community that cares today is in OpenID, and the domain the community has is openid.net, it would make sense to use that domain. A different domain is going to have the same issues of control. I would expect that other members of the community would have concerns if it was rooted at say sxip.org. Happy to have further discussions at IIW, but don't see why the work here should wait until then. Other communities may or may not want to take advantage of what we are doing, and it will be easier for them to understand what we have if we have working code then just more talk about it. To take a step back, the people to decide this should be the people that are doing implementations. Would you clarify David if *you* are implementing, or just sharing your opinion? If anyone implementing would like to do something different, then I'd welcome additional discussion, otherwise I think we should be able to move forward with the proposal. -- Dick On 6-Apr-07, at 2:03 PM, Recordon, David wrote: I think it is great that there is new and innovative work in what you've been doing. I would also think that it would benefit the entire user-centric (and even non-user-centric) community to take advantage of this work regardless of the technology. By having it rooted on openid.net, I think there will be aversion to doing so and other communities will rather jump to the conclusion that the OpenID community is yet again reinventing the wheel by defining common core attributes. This is what I want to avoid. By doing this in a neutral location, not tied to a specific identity technology, it removes this concern as well as does more good for the entire ecosystem. If the ID Schemas project is not the right place to do it, then I see no reason not to create one; I would be happy to front the cost of a domain name if needed. I'd also think this would be something worth discussing at IIW when the entire community comes together. I would really like to see this be something that can be used by OpenID, CardSpace, Higgins, SAML, etc. --David -Original Message- From: Dick Hardt [mailto:[EMAIL PROTECTED] Sent: Friday, April 06, 2007 1:07 PM To: Recordon, David Cc: OpenID specs list; Paul Trevithick; Mark Wahl Subject: Re: PROPOSAL schema.openid.net for AX (and other extensions) If there was something out there already, I would propose we used it. There is not. Just like the SAML crowd has accused the OpenID crowd of reinventing an identity protocol (AKA reinventing the wheel) -- the AX proposal has some unique concepts that people like Paul and Mark think are quite innovative. Other schemas don't support them. I have cc'ed Paul and Mark in case they can point to some new work that we can take advantage of today. Other responses inserted: On 6-Apr-07, at 11:49 AM, Recordon, David wrote: As I've stated in the past, I have no problem with using schema.openid.net to define attributes such as the authoritative URI for an OpenID URL, i-name, etc. I do have a problem with using this namespace to define an attribute such as a First Name. I do not feel that this community should be dealing with all of the issues such as First Name vs. Given Name, as that is not where the expertise is, let alone it has been done in the past. I also strongly believe that due to the number of other definitions of these attributes, either we as a community should decide to use one of them or work with a project such as ID Schemas to create a set of URIs not tied to the OpenID project that solves both our needs and the needs of others. I do not particularly care where this work would happen and as I've said in the past, I'd be fine with someone just buying a domain to do the work to preserve the speed for getting this bootstrapped while not tying it to OpenID. If really don't care, then you should not care if it is happening in OpenID then. First Name: - http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname This URL could be used. To date they have
