On 20-Jan-06, at 1:37 PM, Pete Rowley wrote:
John Merrells wrote:
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....
Isn't it the _user_ that delegates that authority by providing the
homesite-url in the first place? And hasn't the membersite shown
its willingness to do so by actually performing the function? And
the proof that it did in fact perform the function is the next part
of the verification process - ensuring it sent the fetch-response
message.
The verification process has two steps: delegation check and message
verification. Both are there to guard against different kinds of man-
in-the-middle attacks. The security considerations calls those out.
Interesting question... Do you have a cunning idea that motivated
that? Perhaps a use case for the DIX Use Case ID?
I am looking at how a DMD1 homesite can be implemented using an
external data source / identity authority (say, an LDAP directory
server) using existing http server features (apache). So purely
from that view point I would like to avoid having to have a file
for each "persona".
Ah, OK. Two options I think.
1) The user already has a page, to which there's a url, that's their
persona url. The directory then has an attribute on the user's entry
containing that persona url. The user then adds a delegation tag to
their page delegating auth to your DS-as-a-HS server.
2) The user doesn't have a page, so your DA-as-a-HS effectively has
to provide one. How about you provide a virtual page for each user...
so everything below a base path is mapped onto the same simple page
that just delegates auth to your server. That would make sense for an
enterprise, since they own the enterprise.com domain that both the DS-
as-a-HS runs on and where all the persona urls are hosted.
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.
Different names? So, are you saying the sxip#1 capabilities only
come from sxip and if I want to supply say, a user first name, from
some other authority I would need to name the property differently?
With dmd1yes. The query mechanism is super brain dead simple... you
can reference a property value and that's it.
My name as a self asserted attribute value might be:
dix:/central-naming-authority/name/first
And, my name as a digitally signed third party attribute value might be
dix:/central-naming-authority/signed/name/first
or
dix:/central-naming-authority/name/first.signed
or
something else.
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...
John
_______________________________________________
dix mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dix
