On 17-Mar-06, at 11:23 AM, Robert Yates wrote:
Dick Hardt wrote:
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.
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.
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
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.
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.
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.
(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.
understood, am just wanting to put some requirements on the table
prior to the BOF.
Good to hear them!
-- Dick
_______________________________________________
dix mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dix
