AX and Artifact Binding Charter Proposal

Will Norris will at willnorris.com
Tue Nov 17 01:58:58 UTC 2009


On Nov 16, 2009, at 3:49 PM, Nat Sakimura wrote:

> Right. AX 1.1 is to be expedient so that it will remove the current acute
> pain.
> It should be minimalistic as to the spec change and to the implementation
> change.
> 
> AX 2.0 will be more generic fix, and that is the place we should consider
> whole bunch of issues.
> 
> I agree that there should be discovery way of it in XRD/s for many use
> cases,
> but it seems to me to be in the territory of AX2.0.
> 
> Attached please find the first cut of AX1.1 Draft01.

It looks like you have policy URL defined as an actual AX attribute?  How would that work if the RP is sending the URL to the OP.  Doesn't it need to be a standalone parameter like update_url is?

The attribute schema is extensible... there is nothing stopping someone from creating a "name" attribute in their own namespace.  Nor can we force OPs to release any particular piece of data for users.  So what does it mean for section 7 to say that this particular set of attributes MUST be supported?  supported in what sense?  The OP must understand the request?  Well that's required anyway right, as long as it's a well-formed AX request?  I think the most we can do here is to *encourage* use of these attribute names.


> I am still using axschema.org but shorter ones in the spirit of bit.ly would
> be preferable. Also, perhaps we should replace all example.com to this URI
> (whether it be axschema or a short one) because that would drive people to a
> standard set of uris.

keep in mind that whatever we use here is going to be somewhat permanent.  Even though AX 2.0 may be incompatible with 1.X (due to a richer message format, or whatever), it's quite likely that we'll still want to use the same attribute URIs.

Just curious, but why are we stressing too much on the attribute name length?  I understand we want to keep the message smaller if possible, but isn't that what the artifact profile is going to be for?  Won't this be a moot point then?

-will


More information about the specs mailing list