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
Java RP
I have been thinking that the best contribution I could make to OpenID would be the first enterprise that deploys OpenID into production. OpenID needs more press than it is receiving and by showing that a large Fortune enterprise is using would be a big win. I do however have one constraint in that the absolute fastest way of accomplishing deployment would be for me to identify a 100% unrestricted open source Java RP code base that I could incorporate. The notion of going through any form of procurement would not allow me to accomplish this goal. Is anyone aware of the existence of a 100% unrestricted open source Java RP code base? * This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. * ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [dev-monkey] Newlines in bio attribute
use a common escape sequence ... may need to define one for AX anyways ... On 10-Apr-07, at 2:07 PM, Rowan Kerr wrote: The OP doesn't like newlines in attribute values. Which isn't that surprising because handling of newlines isn't even described in the OpenID AX spec yet. But, if we want to allow people to submit a bio to the profile site, we'll have to deal with them. One possible solution: Have Sxipper client and the Profile site define a common way of escaping newlines in attribute values. - Sxipper would replace newlines with a token before sending message to OP. - Profile site would replace tokens with newlines before saving to database. Thoughts? -Rowan ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: in favor of allowing a fragment in a URI for metadata for an attribute type
btw: my main driver in stating +1 is that I was concerned with how it would be implemented, and given that Mark has the one working parser and is ok with it, then my concern has disappeared! On 10-Apr-07, at 5:52 PM, Dick Hardt wrote: Good argument Mark, I concur. +1 -- Dick On 10-Apr-07, at 4:52 PM, Mark Wahl wrote: Section 4.3 of http://openid.net/specs/openid-attribute-types-1_0-02.html suggests that in URIs defined for attributes for OpenID AX, URI fragment specifiers should not be used. Now I'm no RDF expert, but I'm in favor of allowing fragments, and perhaps even encouraging them. I'd prefer this statement be removed from subsequent versions of the OpenID AX, in order to not dissuade other schema developers from using fragments. Here are some points for discussion on that topic, I'd be interested in hearing feedback esp. from other RDF implementors. 0. Some servers will have but a single, small, fixed schema. I'd rather those servers be able to reference and serve a single RDF file with their complete schema, instead of needing to break that schema into a bunch of little schemas. For example, suppose a server only supports FOAF. Now FOAF does not use fragments for the property definitions for its attribute types, but the attribute types defined in FOAF are not currently resolvable to an RDF document that describes those attribute types. If xmlns.com where the FOAF RDF is hosted were to implement having these attribute type URIs used in FOAF be resolvable, they would either need to - create a few dozen little RDF files that together mirror the content of foaf.rdf, or - implement a URI rule that http://xmlns.com/foaf/0.1/* returns foaf.rdf If I were redefining FOAF, I'd have its attributes be defined as fragments, so that there is only one base URI for the FOAF schema. (Also to give them RDF class definitions, see below). 1. It appears to be current practice for RDF representations of metadata for attributes in Higgins to use fragments. In OWL-based systems, the RDF object at the base URI of the document is an OWL Ontology. In Higgins, which uses OWL, the object at the base URI is an OWL Ontology that 'imports' the Higgins Ontology. The RDF file for an attribute contains an OWL Class for the attribute named by a fragment,e.g., #Firstname, and several related OWL properties and RDF instances in that same file that add structure to that class. 2. In our 'schemat' implementations which attempt to generate RDF for existing schemas of 'legacy'/'installed base' protocols, it is desirable to be able to have additional, named OWL classes, RDF objects, and other modelling and descriptive data definitions that are shared across multiple attributes of a single schema. For example, a schema may define its own value syntax and matching rules, and wish to share those syntaxes and matching rules across the attributes of that schema. It would be desirable if there could be a single RDF file which contains the attribute type metadata, the syntax definition and matching rule definition, rather than needing to have the attribute type metadata in a set of files that are separate from the syntax definitions and matching rule definitions, or are duplicated in those files. 3. I find that in our implementation 'schemat' of identity metaschema attribute metadata retrieval that is a definite performance gain if all the schema elements for a particular schema can be retrieved in a single HTTP GET. It is likely that an implementation interested in an attribute Firstname of a particular schema would also be seeing a few other attributes Lastname, Middlename etc of the same schema, and it would be good if a GET that retrieves the data for Firstname also gives the implementation the rest of the schema so that it does not need to keep going back and GETing for each attribute type. 4. Requiring that each be in a separate document would likely lead to duplication of metadata, particularly Dublin Core metadata that describes the schema as a whole. I feel it would be better if the RDF object at the base URI has the Dublin Core metadata for the schema as a whole, and that the Attribute Type Metadata is a class named by a fragment below that base URI. 5. (appeal to authority) http://www.w3.org/DesignIssues/Fragment.html This means that identifiers for arbitrary RDF concepts should have fragment identifiers. Mark Wahl Informed Control Inc. ___ 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: Java RP
Hans- I didn't see XRI support in joid - was I mistaken? -Gabe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Granqvist, Hans Sent: Wednesday, April 11, 2007 9:31 AM To: Dick Hardt; McGovern, James F ((HTSC, IT)) Cc: specs@openid.net Subject: RE: Java RP Or this library (also ASF 2.0) for creating both OP and RP, which follows a slightly different API approach: http://code.google.com/p/joid (If you're coming to JavaOne in May, there will be a presentation on it.) -Hans -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt Sent: Wednesday, April 11, 2007 9:15 AM To: McGovern, James F ((HTSC, IT)) Cc: specs@openid.net Subject: Re: Java RP The OpenID4Java library is licensed under Apache 2.0 -- a very commercial friendly license source development here: http://code.google.com/p/openid4java/source package here: http://code.sxip.com/openid4java/ -- Dick On 11-Apr-07, at 6:37 AM, McGovern, James F ((HTSC, IT)) wrote: I have been thinking that the best contribution I could make to OpenID would be the first enterprise that deploys OpenID into production. OpenID needs more press than it is receiving and by showing that a large Fortune enterprise is using would be a big win. I do however have one constraint in that the absolute fastest way of accomplishing deployment would be for me to identify a 100% unrestricted open source Java RP code base that I could incorporate. The notion of going through any form of procurement would not allow me to accomplish this goal. Is anyone aware of the existence of a 100% unrestricted open source Java RP code base? ** *** This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. ** *** ___ 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 ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Java RP
Hi Gabe, Unfortunately joid doesn't support XRIs --- lack of resources/time. If you or anyone else want to work on a patch with (or without) me, let me know and we'll make it happen! -Hans -Original Message- From: Gabe Wachob [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 11, 2007 10:35 AM To: Granqvist, Hans; 'Dick Hardt'; 'McGovern, James F ((HTSC, IT))' Cc: specs@openid.net Subject: RE: Java RP Hans- I didn't see XRI support in joid - was I mistaken? -Gabe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Granqvist, Hans Sent: Wednesday, April 11, 2007 9:31 AM To: Dick Hardt; McGovern, James F ((HTSC, IT)) Cc: specs@openid.net Subject: RE: Java RP Or this library (also ASF 2.0) for creating both OP and RP, which follows a slightly different API approach: http://code.google.com/p/joid (If you're coming to JavaOne in May, there will be a presentation on it.) -Hans -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt Sent: Wednesday, April 11, 2007 9:15 AM To: McGovern, James F ((HTSC, IT)) Cc: specs@openid.net Subject: Re: Java RP The OpenID4Java library is licensed under Apache 2.0 -- a very commercial friendly license source development here: http://code.google.com/p/openid4java/source package here: http://code.sxip.com/openid4java/ -- Dick On 11-Apr-07, at 6:37 AM, McGovern, James F ((HTSC, IT)) wrote: I have been thinking that the best contribution I could make to OpenID would be the first enterprise that deploys OpenID into production. OpenID needs more press than it is receiving and by showing that a large Fortune enterprise is using would be a big win. I do however have one constraint in that the absolute fastest way of accomplishing deployment would be for me to identify a 100% unrestricted open source Java RP code base that I could incorporate. The notion of going through any form of procurement would not allow me to accomplish this goal. Is anyone aware of the existence of a 100% unrestricted open source Java RP code base? ** *** This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. ** *** ___ 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 ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
