On 20-Jan-06, at 4:15 PM, Pete Rowley wrote:
With dmd1yes. The query mechanism is super brain dead simple...
you can reference a property value and that's it.
So, what is a home site to do if sxip attributes are requested?
Run off to sxip.net with an intermediate request (utilizing a
previously agreed trust), or send the user as a membersite with a
fetch-request, fail the request? Seems to me that the membersite
ought to be getting those attributes from sxip.net, who is acting
as a home site, nobody else needs to be involved - not even the
draft :)
There's no connection between the names of the attributes and where
the attribute values are actually stored. I can store 'dix://sxip.net/
name=john' anywhere I want to. The idea of the authority in the name
is to provide anyone with a domain name their own piece of namespace
to create whatever property names they want.
Or we could extend the query language to make this type part of the
request, but I'm trying to avoid yet another query language...
Perhaps this is the missing dix#1 capabilities, but the benefits of
this are substantially reduced if instead of identity silos, we end
up with attribute silos. The example attributes that are sxip#1 in
that document are prime candidates for dix#1, and sxip#1 if
anything, should be a separate draft detailing that schema - and
btw, where do the dix#1 capabilities fit into this model, who
supplies those, or is dix#1 the (to come) common schema as I am
hoping?
I have to say I am not sold on the idea of compartmentalizing
properties first by source.
I think most of this comment was based on your misunderstanding
above... so no silos....
I would rather see a property type schema where the source of the
property is not tied down, only its meaning. The source of the
property can be disclosed (as a signature) for those membersites
that care, then user supplied attributes may simply not be signed.
In fact, in many common cases the source _will_ be the user anyway.
That's exactly what I think we need and what I believe dmd1 enables.
dix use case:
About 10 years ago I realized amazon basically had the monopoly on
my book buying, then video buying, then whatever because the
barrier for me was filling out another form with a bunch of details
I don't have memorized. Nothing has changed in those 10 years.
So, I want to go to Barnes and Noble and buy a book without filling
out any forms, and without "joining" the website in any way, I want
a one time transaction just like I get in a store, and given that I
am authenticated with my homesite I want a one click transaction.
All details supplied are no more or less trustworthy than those I
would type in myself even if my browser were acting as the homesite.
This doesn't work if I have amazon#1 properties and B&N want B&N#1
properties. It should be hard for that situation to arise, and the
least path of resistance should be an ietf draft detailing the
generic schema.
Great example of the rathole I don't want this group to go down.
There are various social models for working out agreements for the
names of things. Standards bodies seem to be a pretty bad one. XML
dodged this one quite nicely, creating a schema language and
devolving the problem to those who cared most about resolving them. I
don't really want to get too into this now though. Another great
conversation best handled over a beer?
John
_______________________________________________
dix mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dix
