XDI Access control (was Re: [xdi] Minutes: XDI TC Telecon Thursday 1-2PM PT 2010-06-03)

Let's continue this via e-mail..

My own answer to all the questions in the list I sent would be "yes".
I guess the real question is if these functionalities should be part of the core XDI spec, or if they should be optional / extensible / application-specific.

I'd say the core XDI spec should define (or at least mention the need for) a "default" behavior in cases where no link contract exists.
Everything else (e.g. XDI endpoints "belonging to a user") might be application-specific cases that don't need to be in the spec.

Markus

5) LINK
CONTRACTS

 

Markus
poised the following special questions related to link contracts (but not the
link contract format itself):

 

- If link
contracts are enabled at an XDI endpoint and no link contracts exists, what is
the "default" behavior? Allow nothing? Allow only $get?

- Can an
XDI endpoint have a special notion of the XDI endpoint "belonging" to
a user?

- Is yes,
does that user automatically have "full rights" to the XDI endpoint
outside of normal link contract evaluation?

- As an
alternative to signing XDI messages with a key, can an XDI message contain a
user's password for authentication?

 

We did not
have time to consider these on the call, so we will tackle them in email.

 

In
addition, Bill poised the question: Rather than say will XDI use auth
mechanism A or B, what are people's thoughts on considering a broader mechanism
support so that implementors can decide? I'm specifically thinking of support
for using SASL mechanisms (see links below):

 

 http://asg.web.cmu.edu/sasl/

http://en.wikipedia.org/wiki/Simple_Authentication_and_Security_Layer