Subject: [dix] use cases / requirements for extranet collaborations

From: Robert Yates <[email-masked]>
Date: Fri, 17 Mar 2006 10:28:48 -0500

One of the reasons that we are interested in DIX is that it may help our 
collaborative products span corporations. Before the BOF next week I 
wanted to jot down some use cases that we have so the discussion can see 
whether it thinks that these areas lie within the scope of the DIX protocol.

There is a set of collaborative applications that allow a group of 
individuals to collaborate privately with each other.  They provide a 
space where the individuals can post documents, discussions threads, 
project milestones, etc..  Access to this space is limited to members of 
the space, so the data is not publicly available.  Examples of this kind 
of software include Microsoft Sharepoint (Team Sites), Lotus Quickplace 
and private Wikis.

Typically, the membership of the space is managed by the spaces owner(s) 
(business end users) and today this membership list is typically limited 
to the employees of the corporation that has deployed the software.  
Many corporations however are increasingly seeking the capability to 
collaborate with their partners / vendors within these spaces and so 
they wish the spaces to be accessible both to their own employees and 
the employees of their partners.

Below I outline some typical flows that exist in this type of 
application today.  These flows are, today, only available to employees 
in the intranet.  We would like to see whether DIX can enable these 
capabilities across the extranet.

1. The space owner adds a new member to the space.  The new member is 
e-mailed a url link to the space along with a welcome message from the 
space owner.
2. Members of the space need to authenticate before being allowed access 
to the space. Their id is checked against the list of members allowed 
into a particular space.
3. The spaces membership list is available to all members of the space.  
This list also makes available the contact details of the members so 
that other members can contact them easily.  This includes contact 
information such as business telephone, e-mail and jabber id.
4. All postings to the space display who made the posting.
5. Members keep track of activity in the space by subscribing to the 
space's feed.

Some observations of these requirements and dmd1.

Requirements 2 and 4 are met by dmd1
Requirements 1 and 3 cannot currently be met by dmd1.  There's a couple 
of  interesting point here.  Namely that it is the enterprise, not the 
individual that makes the decision about whether to release certain 
attributes about an individual.  It also determines to whom (i.e. which 
partners) those attributes can be released. Also, the individuals 
contact details needs to be available prior to the individual logging 
into the space.  As soon as an individual is added to the membership 
list their contact information should be available to other members in 
the space.
Requirement 5 is not met by dmd1 as "Rich Clients" are presently not in 
scope.

Let me know what you think,

Rob

_______________________________________________
dix mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dix

---

From: Dick Hardt <[email-masked]>
Date: Fri, 17 Mar 2006 09:48:56 -0800

On 17-Mar-06, at 7:28 AM, Robert Yates wrote:
> 1. The space owner adds a new member to the space.  The new member  
> is e-mailed a url link to the space along with a welcome message  
> from the space owner.
> 2. Members of the space need to authenticate before being allowed  
> access to the space. Their id is checked against the list of  
> members allowed into a particular space.
> 3. The spaces membership list is available to all members of the  
> space.  This list also makes available the contact details of the  
> members so that other members can contact them easily.  This  
> includes contact information such as business telephone, e-mail and  
> jabber id.
> 5. Members keep track of activity in the space by subscribing to  
> the space's feed.
>
> Requirements 1 and 3 cannot currently be met by dmd1.  There's a  
> couple of  interesting point here.  Namely that it is the  
> enterprise, not the individual that makes the decision about  
> whether to release certain attributes about an individual.  It also  
> determines to whom (i.e. which partners) those attributes can be  
> released. Also, the individuals contact details needs to be  
> available prior to the individual logging into the space.  As soon  
> as an individual is added to the membership list their contact  
> information should be available to other members in the space.
> Requirement 5 is not met by dmd1 as "Rich Clients" are presently  
> not in scope.

Personally, I think that a goal of DIX would be to provide the basis  
for your to solve your problem above. Some of the aspects are part of  
your application, rather then the protocol. From what I gather from  
the problem statement, an email address is likely the easier  
identifier for identifying users. A SAML assertion linking the email  
address and the persona-url could be made by a third party, either  
the server at the domain of the email address or a trusted 3rd party.

This allows the space owner to add email address to the space. The  
new member gets the email, and logs in proving they own they email by  
providing the SAML assertion and their persona-url. I think this  
covers (1) above. (3) is covered by the application displaying the  
list of email addresses of the members.

(5) would be nice to solve real-soon-now. Not sure what is  
appropriate or standard within IETF for setting up a subgroup to work  
on that. We still don't have a WG for the core stuff in DIX.

-- Dick

---

From: Robert Yates <[email-masked]>
Date: Fri, 17 Mar 2006 14:23:12 -0500

Dick Hardt wrote:

>> access to the space. Their id is checked against the list of  members 
>> allowed into a particular space.
> your application, rather then the protocol. 

Agreed, that some of what I wrote above is part of our application e.g 
the e-mailing aspect, but steps 1 and 3 depend on the flow of 
identifiers about an individual from a domain that knows them to a 
domain that wants to know them.  Our application needs to know part of 
the users Digital Identity, namely their e-mail, their display name, and 
their jabber-id.  Shouldn't DIX be capable of moving this information 
about? Is that not core to the DIX protocol?

 From the DIX charter:

/"To specify a protocol for moving identity information between parties, 
and a system architecture that enables the development of software 
agents to manage this exchange."

/It's certainly within DIX scope to request this information for the 
user at the browser.  How is the delineation being made that the use 
case above is not considered core and would require SAML to provide a 
solution?  Is it due to the fact that it is the users corporation that 
has provided consent to release these attributes and not the user?  Is 
it that the user is not currently at the browser? I just wonder where 
the line is being drawn and would be interested in seeing this discussed 
at the BOF.

> From what I gather from  the problem statement, an email address is 
> likely the easier  identifier for identifying users. A SAML assertion 
> linking the email  address and the persona-url could be made by a 
> third party, either  the server at the domain of the email address or 
> a trusted 3rd party.

I agree that an e-mail address is potentially easier from an end user 
perspective, but let's say its o.k. for the space owner to identify 
members by their persona-url.  All our application now needs is the 
ability to look up other parts of this user's identity, namely their 
e-mail, their display name and their jabber-id for a given persona-url?  
Is this not within the scope of DIX?

> list of email addresses of the members.

3 is not quite covered as we need more than just e-mails, we need a 
display name, their jabber id so they can be instant messaged and also 
their phone number.

> on that. We still don't have a WG for the core stuff in DIX.

understood, am just wanting to put some requirements on the table prior 
to the BOF.

Rob

---

From: Dick Hardt <[email-masked]>
Date: Fri, 17 Mar 2006 11:30:27 -0800

On 17-Mar-06, at 11:23 AM, Robert Yates wrote:

>>> 1. The space owner adds a new member to the space.  The new  
>>> member  is e-mailed a url link to the space along with a welcome  
>>> message  from the space owner.
>>> 2. Members of the space need to authenticate before being  
>>> allowed  access to the space. Their id is checked against the  
>>> list of  members allowed into a particular space.
>>> space.  This list also makes available the contact details of  
>>> the  members so that other members can contact them easily.   
>>> This  includes contact information such as business telephone, e- 
>>> mail and  jabber id.
>> Personally, I think that a goal of DIX would be to provide the  
>> basis  for your to solve your problem above. Some of the aspects  
>> are part of  your application, rather then the protocol.
>
> Agreed, that some of what I wrote above is part of our application  
> e.g the e-mailing aspect, but steps 1 and 3 depend on the flow of  
> domain that wants to know them.  Our application needs to know part  
> of the users Digital Identity, namely their e-mail, their display  
> name, and their jabber-id.  Shouldn't DIX be capable of moving this  
> information about? Is that not core to the DIX protocol?
>
> From the DIX charter:
>
> /"To specify a protocol for moving identity information between  
> parties, and a system architecture that enables the development of  
> software agents to manage this exchange."
>
> /It's certainly within DIX scope to request this information for  
> the user at the browser.  How is the delineation being made that  
> the use case above is not considered core and would require SAML to  
> provide a solution?  Is it due to the fact that it is the users  
> corporation that has provided consent to release these attributes  
> and not the user?  Is it that the user is not currently at the  
> browser? I just wonder where the line is being drawn and would be  
> interested in seeing this discussed at the BOF.

I agree that DIX should be able to move around all the identity data  
you describe.

SAML comes in when you want the data verified by a third party, as  
opposed to the user.

>
>> From what I gather from  the problem statement, an email address  
>> is likely the easier  identifier for identifying users. A SAML  
>> assertion linking the email  address and the persona-url could be  
>> made by a third party, either  the server at the domain of the  
>> email address or a trusted 3rd party.
>
> I agree that an e-mail address is potentially easier from an end  
> user perspective, but let's say its o.k. for the space owner to  
> identify members by their persona-url.  All our application now  
> needs is the ability to look up other parts of this user's  
> identity, namely their e-mail, their display name and their jabber- 
> id for a given persona-url?  Is this not within the scope of DIX?

Yes it is, except that DIX as proposed has the user present the  
email, display name, jabber-id, to the application rather then the  
application "looking it up".

>
>>
>> This allows the space owner to add email address to the space.  
>> The  new member gets the email, and logs in proving they own they  
>> email by  providing the SAML assertion and their persona-url. I  
>> think this  covers (1) above. (3) is covered by the application  
>> displaying the  list of email addresses of the members.
>
> display name, their jabber id so they can be instant messaged and  
> also their phone number.

Do you want those verified by a third party as well, or are you ok  
that the user asserts those? If verified, then they would be need be  
in an assertion. If not, then it is easy to move. Either case, I  
think your problem statement is in scope for DIX.

>> appropriate or standard within IETF for setting up a subgroup to  
>> work  on that. We still don't have a WG for the core stuff in DIX.
>
> understood, am just wanting to put some requirements on the table  
> prior to the BOF.

Good to hear them!

-- Dick

---

From: Robert Yates <[email-masked]>
Date: Fri, 17 Mar 2006 15:15:10 -0500

> I agree that DIX should be able to move around all the identity data  

great, but I just want to clarify a point.  dmd1 today can move around 
all this identity data.  The reason that dmd1 doesn't yet fulfill our 
requirements is that it moves it too late in this process for it to be 
useful to us.  We need the data moved the moment that a space owner adds 
a new user to the space. Do you also agree that DIX should allow the 
identity data to be moved at this point?

> application "looking it up".

do you envision a future draft with the "lookup" capability? in the use 
case, as described, the identity data is needed and the user is not 
around to present it.

> think your problem statement is in scope for DIX. 

Am a little confused here.  If our application is installed by Company X 
who wants to collaborate with members of Partner Y then it is important 
that when we get identity information about a user from Partner Y that 
it is Partner Y's homesite that is making the assertions.

Rob

p.s. just to be clear I am not a "pull" junkie.  I just have problems :)

---

From: John Merrells <[email-masked]>
Date: Fri, 17 Mar 2006 22:01:03 -0800

On 17-Mar-06, at 12:15 PM, Robert Yates wrote:

> The reason that dmd1 doesn't yet fulfill our requirements is that  
> it moves it too late in this process for it to be useful to us.  We  
> need the data moved the moment that a space owner adds a new user  
> to the space.

Why is that? So that other members of the space can browse the  
details of the other members before those members have actually  
entered the space for the first time?

> Do you also agree that DIX should allow the identity data to be  
> moved at this point?

I'm not sure it needs to be.

> do you envision a future draft with the "lookup" capability? in the  
> use case, as described, the identity data is needed and the user is  
> not around to present it.

SPML comes to mind for pushing provisioning data from a directory out  
to an application.
(Although I should state that I haven't looked at SPML for a couple  
of years now.)

>
>>> 3 is not quite covered as we need more than just e-mails, we need  
>>> a  display name, their jabber id so they can be instant messaged  
>>> and  also their phone number.
>>
>> Do you want those verified by a third party as well, or are you  
>> ok  that the user asserts those? If verified, then they would be  
>> need be  in an assertion. If not, then it is easy to move. Either  
>> case, I  think your problem statement is in scope for DIX.
>
> Am a little confused here.  If our application is installed by  
> Company X who wants to collaborate with members of Partner Y then  
> it is important that when we get identity information about a user  
> from Partner Y that it is Partner Y's homesite that is making the  
> assertions.

Your solution above sounds like X pushes a statement about user
A having some attributes to Partner Y.

Dick's suggesting that X creates that same statement but that it
digitally signs it (perhaps making a SAML assertion), then User A
can move the assertion themselves to Partner Y when they first
enter the space. User A can't modify the statement in any way,
so Y is assured that X is making the statement. In the scenario
X is serving as A's Homesite and Y is the Membersite.

John

---

From: Dick Hardt <[email-masked]>
Date: Fri, 17 Mar 2006 22:24:44 -0800

On 17-Mar-06, at 12:15 PM, Robert Yates wrote:

>
>> I agree that DIX should be able to move around all the identity  
>> data  you describe.
>
> great, but I just want to clarify a point.  dmd1 today can move  
> around all this identity data.  The reason that dmd1 doesn't yet  
> fulfill our requirements is that it moves it too late in this  
> process for it to be useful to us.  We need the data moved the  
> moment that a space owner adds a new user to the space.

To echo John's comments, why do you need this?

> Do you also agree that DIX should allow the identity data to be  

I think to move the data as you describe, a tight coupling between  
all parties is required.

>> email, display name, jabber-id, to the application rather then  
>> the  application "looking it up".
>

Would be interested in hearing use cases for where this is needed  
where the user had not already been there.

> from Partner Y that it is Partner Y's homesite that is making the  

The Homesite is the users agent for managing their data. Liberty  
deployments typically combine the identifier authentication and  
property assertion operations. DIX is wanting to separate those so  
that you can provide third party claims from many authoritative sites  
in a single request, and that the Homesite does NOT need to be trusted.

ie. AT&T may claim that my persona has a phone number, VeriSign that  
I have a specific email address, and Air Canada that I am Star  
Alliance Gold. Company X needs to trust AT&T, VeriSign and Star  
Alliance -- but not my Homesite.

> p.s. just to be clear I am not a "pull" junkie.  I just have  

Don't we all? I'm no exception to having problems. ;-)

-- Dick

---

From: Robert Yates <[email-masked]>
Date: Sun, 19 Mar 2006 09:46:22 -0500

> To echo John's comments, why do you need this?

When the space administrator adds a new member to the space, the 
following things currently happen.  Note that at this point in time the 
new member is no where in sight.

1) The new member gets added to the access control for the space.
2) The new member is e-mailed with a welcome message and a link to the 
space.
3) The new member's contact details e.g. phone number, e-mail address, 
jabber id are available to other space members from the space's 
membership list.

Note also that there are some space members that log into the space 
extremely infrequently and with the advent of feeds some may never log 
into the space via a browser.  They're just "observers" of what is 
taking place.  However it is important that their contact details be 
available to other members of the space.

> I think to move the data as you describe, a tight coupling between  

Not sure why you think the coupling is any tighter than the coupling 
between a homesite and membersite.  We're just requesting a set of user 
properties.

> where the user had not already been there.

see above.  We want the user's properties to move when the space admin 
adds them to the membership list, so we can send them an e-mail, and so 
that their contact details are available to others.  This is how the 
products work today, the difference is that today all the members are in 
the corporate LDAP and so the application just "pulls" the data from there.

> Alliance -- but not my Homesite.

k, sorry, have been slow at grasping this fact (as demonstrated by an 
earlier posting of mine), thanks for the explanation. 

Rob

p.s. I notice this statement in the DIX charter.

"The end-user should have control over their identity information and 
always be providing consent for the exchange of any of their information."

I just wonder whether this holds true in the corporation to corporation 
use cases.  In these instances it is the end-user's corporation that 
provides consent for the exchange of their employee's identity 
information.  I think this is an important distinction from the consumer 
space.

---

From: Dick Hardt <[email-masked]>
Date: Sun, 19 Mar 2006 13:56:27 -0600

On 19-Mar-06, at 8:46 AM, Robert Yates wrote:

> following things currently happen.  Note that at this point in time  
> the new member is no where in sight.
>
> 2) The new member is e-mailed with a welcome message and a link to  
> the space.
> 3) The new member's contact details e.g. phone number, e-mail  
> address, jabber id are available to other space members from the  
> space's membership list.
>
> extremely infrequently and with the advent of feeds some may never  
> log into the space via a browser.  They're just "observers" of what  
> is taking place.  However it is important that their contact  
> details be available to other members of the space.

Ok, I think I understand your use case.

Essentially you are saying that someone can be added to a space  
without their permission? :-)

Seriously though, I'm sure there are situations where your use case  
makes sense. In order to solve the other aspects of the identity  
problem, I would expect that server to server communication would  
currently be out of scope

>
>> I think to move the data as you describe, a tight coupling  
>> between  all parties is required.
>
> Not sure why you think the coupling is any tighter than the  
> coupling between a homesite and membersite.  We're just requesting  
> a set of user properties.

The site with the data MUST trust the site requesting the data. ie,  
there is an existing relationship between them. In dmd1, the  
membersite and homesite don't need to have any prior relationship,  
and the user can use one homesite one day, and another another day

>
>>> do you envision a future draft with the "lookup" capability? in  
>>> the  use case, as described, the identity data is needed and the  
>>> user is  not around to present it.
>>
>>
> see above.  We want the user's properties to move when the space  
> admin adds them to the membership list, so we can send them an e- 
> mail, and so that their contact details are available to others.   
> This is how the products work today, the difference is that today  
> all the members are in the corporate LDAP and so the application  
> just "pulls" the data from there.

Sounds like LDAP is a solution now. Why not keep using it?

>> property assertion operations. DIX is wanting to separate those  
>> so  that you can provide third party claims from many  
>> authoritative sites  in a single request, and that the Homesite  
>> does NOT need to be trusted.
>>
>> ie. AT&T may claim that my persona has a phone number, VeriSign  
>> that  I have a specific email address, and Air Canada that I am  
>> Star  Alliance Gold. Company X needs to trust AT&T, VeriSign and  
>> Star  Alliance -- but not my Homesite.
>
> k, sorry, have been slow at grasping this fact (as demonstrated by  
> an earlier posting of mine), thanks for the explanation.
> Rob
>
> "The end-user should have control over their identity information  
> and always be providing consent for the exchange of any of their  
> information."
>
> I just wonder whether this holds true in the corporation to  
> corporation use cases.  In these instances it is the end-user's  
> corporation that provides consent for the exchange of their  
> employee's identity information.  I think this is an important  
> distinction from the consumer space.

I agree there are differences. I have found this useful discussion.

-- Dick

---

From: Robert Yates <[email-masked]>
Date: Sun, 19 Mar 2006 18:44:37 -0500

> without their permission? :-)

Yes :) there are a lot of similar use cases in the consumer space that I 
think DIX needs to accommodate, e.g. in flickr I can share photos with a 
limited set of contacts, in kodak gallery the same thing.  These sites 
all send the user an e-mail stating something like "Rob has shared some 
photos with you, click here to access the photos".  I can imagine ways 
that this could work with dmd1, I could type in the user's e-mail 
address and their persona-url, or some secret in the mail message the 
user receives could be used that allows the user to type in their 
persona-url and then the service associates this e-mail with that 
persona-url.  These approaches however seem a little strained to me.  Is 
there something special about an e-mail address that needs to be better 
reflected in future revisions of dmd1?

>> between a homesite and membersite.  We're just requesting  a set of 
>> user properties.
>

Am not sure that I would describe an existing relationship as a "tight 
coupling".  How different is this to me instructing my homesite that it 
can always release my credit card information to amazon.com, and that it 
can do so without requiring me to confirm its release.  I have always 
been assuming that this is why the membersite can optionally send its 
signature.

Given this fact, dmd1 is within sniffing distance of being able to 
fulfill the use case that I have described previously.  Our server could 
issue a fetch request directly to the homesite url.  The homesite could 
check that the request is coming from a membersite with which an 
existing relationship exists and hence immediately returns the form to 
post.  Although ugly and not an approach that I would advocate our 
server can parse the form in the response from the homesite and get the 
information that it requires.

If a WG is formed, and I wish you all the best of luck this week in 
Dallas, then I think it worth exploring some options to see if these use 
cases can be accommodated without placing a significant burden on 
homesites. Given how close dmd1 is to meeting these requirements we may 
surprise ourselves and find an easy solution. I would not be too hasty 
in removing these use cases from scope.

> Sounds like LDAP is a solution now. Why not keep using it?

Is possible, but I don't think enterprises like placing their ldaps on 
the public internet.  Securely proxying http requests is well 
understood.  Am not sure that the same can yet be said for ldap.

Rob

---

From: Dick Hardt <[email-masked]>
Date: Sun, 19 Mar 2006 22:55:38 -0600

On 19-Mar-06, at 5:44 PM, Robert Yates wrote:

> Yes :) there are a lot of similar use cases in the consumer space  
> that I think DIX needs to accommodate, e.g. in flickr I can share  
> photos with a limited set of contacts, in kodak gallery the same  
> thing.  These sites all send the user an e-mail stating something  
> like "Rob has shared some photos with you, click here to access the  
> photos".  I can imagine ways that this could work with dmd1, I  
> could type in the user's e-mail address and their persona-url, or  
> some secret in the mail message the user receives could be used  
> that allows the user to type in their persona-url and then the  
> service associates this e-mail with that persona-url.  These  
> approaches however seem a little strained to me.  Is there  
> something special about an e-mail address that needs to be better  

Not sure what you mean about something being special about the email.  
Per my earlier email, providing the email as an identifier to  
bootstrap a user account was something I envisioned would happen. All  
other aspects about the user are provided by the user when they login  
the first time.

btw: Funny you mention flickr having been the first outside investor  
and board member ... they were on track to put in SXIP until Yahoo!  
bought them.

>>> coupling between a homesite and membersite.  We're just  
>>> requesting  a set of user properties.
>>
>> The site with the data MUST trust the site requesting the data.  
>> ie,  there is an existing relationship between them. In dmd1, the   
>> membersite and homesite don't need to have any prior  
>> relationship,  and the user can use one homesite one day, and  
>> another another day
>
> Am not sure that I would describe an existing relationship as a  
> "tight coupling".  How different is this to me instructing my  
> homesite that it can always release my credit card information to  
> amazon.com, and that it can do so without requiring me to confirm  
> its release.  I have always been assuming that this is why the  
> membersite can optionally send its signature.

Currently, the membersite does not need to have any method of proving  
who it is, which lowers the barrier to adoption.

> Dallas, then I think it worth exploring some options to see if  
> these use cases can be accommodated without placing a significant  
> burden on homesites. Given how close dmd1 is to meeting these  
> requirements we may surprise ourselves and find an easy solution. I  
> would not be too hasty in removing these use cases from scope.

I have heard from quite a few people that we need to keep a narrow  
scope.

> Is possible, but I don't think enterprises like placing their ldaps  
> on the public internet.

agreed

> Securely proxying http requests is well understood.  Am not sure  
> that the same can yet be said for ldap.

LDAP over TLS can be done.

For the same reasons why they don't want to put their LDAP servers  
out there, I think you have the same issues around "pulling" data  
using any other protocol.

-- Dick