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

[Drummond Reed <drummond.reed@xdi.org>]

Indeed we agreed to continue several of the topics we didn't get to in the last call on email. Markus proposed a blanket answer to his four link contract questions; I'll provide a little more fine-grained answers:

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

My view is that it depends on the the XDI endpoint. For example, if the endpoint serves up only public XDI data, then no link contract would be required to read it. However if would be better if that was explicitly declared at the endpoint with a single link contract that declares the entire context public.

The simplest answer (which is why it gets my vote) is for link contracts to be the standard means of XDI data access at every XDI endpoint with one exception -- the endpoint authority (see below). Thus if you have a XDI endpoint that is COMPLETELY open to everyone else, then it only needs one link contract declaring that.

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

Absolutely. In fact that's shown in the example PDX XDI document at http://wiki.oasis-open.org/xdi/PdxExample. The following lines at the top...

$   <-- Pattern: Context Self Descriptor -->
        $is$a
                ($xdi$v$1)      <-- Pattern: Context Type -->

                ($pdx$v$1)
        $is($xdi$v$1)   <-- Pattern: Context Authority -->
                =!1111.aaaa.bbbb.cccc!9999.xxxx.yyyy.zzzz

...declare that the authority for this XDI context (the $is($xdi$v$1) predicate) is =!1111.aaaa.bbbb.cccc!9999.xxxx.yyyy.zzzz. That's the XDI subject that has "root privileges" to this XDI context.

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

Yes. Note that more than one XDI subject could be listed, so it could be more than one person. A group could also be listed, but we need to have a discussion about giving permissions to groups.

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

Yes - or whatever other authentication mechanism the XDI endpoint wants to enforce with the XDI authority.

=Drummond

On Sat, Jun 5, 2010 at 11:59 AM, Markus Sabadello <markus.sabadello@xdi.org> wrote:

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