On 20-Jan-06, at 11:48 AM, Pete Rowley wrote:
The draft identifies the user via a persona url, and there is a
parameter in the fetch request that may request the persona url
(and another which requests multiple persona urls). To clarify,
the intention is that after/during homesite user authentication
that the persona-url is resolved for the homesite i.e. that the
user chooses the persona-url at some point or alternatively it is
chosen for them by the homesite based on their local credentials.
To clarify further - it is not a requirement that this persona-url
be resolvable in any meaningful sense other than as an arbitrary
identifier.
Dmd1 defines the Persona URL to be a URL... so it's syntax is limited
to that of a URL, so it's not totally arbitrary.
Does it have to be resolvable? Well it's optional whether the
Membersite fetches the Persona Page at the end of the Persona URL to
check for the Delegation Tag to ensure that the Homesite stated in
the fetch-response message really has been delegated authority to
authenticate that Persona URL.... so in theory if the Membersite
didn't do that then it wouldn't really be optional... but the
Homesite doesn't know if the Membersite is going to perform that part
of the Verification Process so it must provide a resolvable Persona
URL for the user. Of course if that were a useful feature then we
could have a capability for the Membersite to declare that it wasn't
going to verify the Persona URL...
Interesting question... Do you have a cunning idea that motivated
that? Perhaps a use case for the DIX Use Case ID?
Also, what responsibilities does the homesite have for the validity
of the information supplied?
None.
Dmd1 doesn't cover claims, just permits them to be moved around.
In the charter discussions we've said that an asserting party can make
claims about an identity... which can be acquired by the user, stored
in their agent, and presented to relying parties upon request.
Should it only return information from a trusted source or is it
acceptable to ask the user for data it doesn't know about?
The Homesite can ask the user for self asserted attribute values.
It's up to the Membersite whether self asserted attribute values or
third party asserted attribute values are acceptable. It does this in
the fetch request by listing the properties it requires... self
asserted and third party asserted have different names.
Should this be a protocol level decision?
MS decision, by the protocol facilitates it.
Assuming some level of trust has been established between the
homesite and the membersite it might be useful to be able to
specify this on an individual attribute basis.
Indeed. The above explains how that happens I think.
Or maybe I am way off base here, and the intent is that the
homesite gives what it can and it is up to the homesite
think you must mean membersite there.
to get the rest, possibly resulting in a store-request?
Assuming the above change: Exactly!
Cheers
John
_______________________________________________
dix mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dix
