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.
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?
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.
(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.
Rob
_______________________________________________
dix mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dix
