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

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

Yes, I like the idea of supporting various access control mechanisms in 
an extensible way.
Another requirement I can think of is OAuth tokens.

E.g.
1. User goes to pizza delivery site and places an order.
2. Instead of entering personal data at the pizza site, they enter an 
i-name, which points to a PDS XDI endpoint.
3. Since the pizza site has no link contract with the PDS (and 
instantiating a link contract just for the purpose of a one-time 
transaction is impracticable), the pizza site obtains an OAuth access 
token from the user's PDS. [Need to figure out how the OAuth endpoint is
 discovered]
4. With the OAuth access token the pizza site can now send a $get 
message to the user's XDI endpoint, even though there's no link contract
 (or only a default "catch-all-OAuth-requests" link contract).

I don't know SASL well enough. I imagine we would simply include the 
various kinds of credentials in the XDI message.

With signature:

=!F83.62B1.44F.2813   <-- =drummond -->
    $get
        /
            =!91F2.8153.F600.AE24   <-- =markus -->
                +name
                +email
                +tel
    $sig$rsa
        "CCn ... =="

With password:


=!91F2.8153.F600.AE24   <-- =markus -->

    $get

        /

            =!91F2.8153.F600.AE24  <-- =markus -->

                +name

                +email

                +tel

    $password

        "s3cr3t"

With OAuth token:



$   <-- anonymous -->


    $get


        /


            =!91F2.8153.F600.AE24  <-- =markus -->


                +name


                +email


                +tel


    $oauth


        "ABC1234567890"


Can something like that be done with SASL?

Markus

On Thu, Jun 10, 2010 at 7:36 PM, Barnhill, William [USA] <barnhill_william@bah.com> wrote:

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

• I think we touched on, but didn't develop, the need for link contract negotiation similar to content-type negotiation in HTTP.
• If no link contract exists then I think the requestor should need to negotiate the contract with the authority which might or might not allow for a non-authenticated contract, or a default contract. This matches what Drummond said "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."
  I think we should provide the option to implementers that the only valid link-contracts are those that have been pre-negotiated. In this case I think attempting to access an XDI endpoint without the requisite link contract token should return the exact same result as if there was no XDI endpoint there.
• I think we should discuss link contract inheritance through delegation. If I access an XDI endpoint at XRI @example and then an XDI endpoint at @example+people, do we want a mechanism for @example+people stating that it honors (or doesn't honor) link contracts with @example? 
• In terms of defaults, do we need a mechanism to express link contracts about link contracts - such contracts would be used between data authorities to express how they trust each other's contracts, or don't. 

 

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

• My initial reaction is that there can't be any XDI endpoint that doesn't "belong" to some entity, be it a person or a legal entity such as a corporation or a social entity such as a community. If we're all about user-centric data and all data has some originating authority, then I'd think all data would need to 'belong'.

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

• I'd say no, but not sure. The reason I'd say no is that they may have full rights to the data (and we might require a data export dump only endpoint to be available to the owner) but they may not have rights to the data broker hosting their endpoint per the link contract between their data broker and themselves. This is similar to how we own our personal email accounts that we use outside of work, but if we don't pay our monthly bill to the ISP we can't access them.
• On groups have link contracts, I propose we treat social and corporate entities just like we do individuals, though still requires discussing how a user dons the 'identity hat' of the group in XDI data exchanges

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

• As I mentioned before I'd recommend we standardize on an authentication mechanism framework such as SASL and provide the means for that to be used. Then any authentication method supported by SASL is usable

 

Kind regards,

 

Bill Barnhill

Booz Allen Hamilton - Rome, NY

315-330-7386  | william.barnhill.ctr@rl.af.mil | barnhill_william@bah.com

 

 

---

From: markus.sabadello@gmail.com [markus.sabadello@gmail.com] On Behalf Of Markus Sabadello [markus.sabadello@xdi.org]
Sent: Saturday, June 05, 2010 2:59 PM
To: Drummond Reed
Cc: OASIS - XDI TC
Subject: [xdi] 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