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

[Markus Sabadello <markus.sabadello@xdi.org>]

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