Re: Authentication Protocols for Non-browser Apps
Gabe Wachob wrote: Hi Mart- I'm trying to figure out if what you are proposing covers the same use case that I discussed at http://openid.net/pipermail/general/2007-March/002005.html I'm not clear actually what you are trying to do with HTTP Authentication, and it may be completely unrelated to my use case, or it could be squarely in the same place. In your proposal, is there any interaction with a user? If so, when? All I see is that the caller sends a signature with the authenticated request. Is this implying that the caller performs some function with the OP to generate this signature? How does this happen? Can I use an existing OP with my URL or XRI to generate this signature? If so, how? The HTTP authentication bit does not specify how the signature is obtained. This is because when some application service is authenticating as itself it can maintain its own associations and generate its own signature without the indirection. Where the Signature Request Protocol comes in is making this protocol applicable to user authentication as well. Unfortunately, it *does* require the OP to support an additional protocol mode where the user is authenticated using HTTP authentication (or some other machine-interpretable authentication) rather than HTML forms and redirections. The flow I'm expecting for the latter is, to take the Last.fm client[1] as an example, that the user will enter an identifier URI into the preferences dialog where currently a username/password is entered. When the client-side app needs to make a request, it'll first do an unauthenticated request and see what HTTP authentication mechanisms are supported, and then prompt the user for appropriate credentials. In the future, I'm hoping that the signature-fetching steps will be replaced with call into an installed system service which will prompt the user to release a signature, thus avoiding the need for the user to give up the credentials to the client app and allowing the user to approve each application is is often done with a desktop firewall. [1] http://www.last.fm/tools/downloads/ ___ 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: in favor of allowing a fragment in a URI for metadata for anattribute type
+1 as well. Very well articulated. An interesting side note: XRI supports a # fragment for backward compatibility with URI/IRI syntax, but in practice its rarely used since XRI syntax is already polyarchical, i.e., any XRI can be put in the context of another XRI. # is just one such context (document local). So XDI dictionaries, which use XRIs to identify attributes, can have all the same general properties that Mark describes (except #5, which applies only to URLs), only they don't have to explicitly be expressed as fragments. =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt Sent: Tuesday, April 10, 2007 5:53 PM To: Mark Wahl Cc: OpenID specs list; ID Schemas Subject: Re: in favor of allowing a fragment in a URI for metadata for anattribute type 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
Attribute Exchange draft 5
Thanks everyone for the good feedback and discussions during the last week. I went through the messages and added clarifications and modifications for the issues where there seemed to be consensus. Since there were a handful of changes, I've tagged the result and asked David to put draft 5 up on openid.net, so we can use it as a base for sorting out the remaining issues. You can see AX draft 5 here: http://openid.net/specs/openid-attribute-exchange-1_0-05.html The outstanding issues so far (and today's change log) are summarized below. Please voice your opinion about them! (Separate threads for each discussion would help with tracking.) If I've missed anything or there are new issues and feedback please bring that up, too. == How does the RP request all the values available at the OP for an attribute? Options: magic count value = -1? others? The OpenID realm has no meaning in a store request; need to be clarified? Suggestions? Todo: Example for the SReg to AX upgrade path. Newlines are not allowed in openid field values; how do we deal with newlines in attribute values? How can the RP determine the maximum value length that an OP will support for a particular attribute? What is the maximum length of an alias string that an RP can expect an OP to support? How does the RP determine the schema of the provider to know what to ask for? OP is not required maintain preserve the order of the attribute values internally and in a fetch responses; does it needs clarification in the spec? Is it legal for the values of a multi-valued attribute to be bytewise identical (.fav_movie.1=X, .fav_movie.2=X)? How can the RP determine the maximum value count that an OP will support? What is the locale of the status messages in the protocol? == CHANGELOG: Removed OpenID error responses reference - AX doesn't actually use them. Added clarification note about OPs dereferencing the attribute URIs in order to dynamically assist users. Mark Wahl's issue #2: http://openid.net/pipermail/specs/2007-April/ 001565.html Refactored required / if_available description to use the same phrases; dropped mention of 'error condition'. Modified count and blank attribute values: - OP may return less than the number of requested attributes - OP must not return a .value. field if a value was not provided - count=0 is allowed to explicitly state that no value was provided for an attribute - for count=1 both response formats (with or without count) are allowed http://openid.net/pipermail/specs/2007-April/001430.html http://openid.net/pipermail/specs/2007-April/001469.html update_url in fetch requests: - consequent updates use the OpenID protocol - must match the realm in the OpenID message - use of 404 for unsubscribing Clarified the intent / usage of store requests. More store requests clarifications: - error message intended to be presented to the user - alias used to associate values with type URIs within the message - rearange the intro paragraphs Disallowing periods in attribute aliases. == Thanks, Johnny ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
