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

�

�