On 18-Jan-06, at 8:02 PM, Suresh Venkatraman wrote:
Before putting forth a show of hands, I think we should hammer out the
proposed vocabulary, the scenarios, and specified methods in the
charter
before a vote. In fact, is that not the purpose of this forum? I
will start
with my take on the charter.
On vocabulary... I don't mind what things are called just that we
agree on
what they are... which could be an endless debate. I used the
terminology
from this lexicon... even though I don't agree with all their
definitions...
http://www.identitygang.org/Lexicon
Scenarios... There's aren't any in the charter. I think there's one
example.
I felt that one illustrative one would make the document more
accessible.
Reputation Data - We should clarify this within the scenario...
I'm happy to remove it... as the rest of the text is fine without it.
A reasonable
work item for a working group would be to document a set of motivating
use cases to inform the decisions of the group. Would that be
preferable?
Scenarios - Web sign-on and forms is not the only time user
identity needs
to be asserted. XMPP and SIP sessions are important and different
scenarios
that require identity and profiles.
A good example for a draft. I'm sure others on the list have good
ideas too.
Not sure what we'd call this: 'Use Cases'? Or who'd write it? I'm kinda
swamped myself. Suresh? Anyone?
Not to discount logging into weblogs but
non-HTTP scenarios are just as important. This protocol should not be
service specific.
The draft proposed charter makes that clear doesn't it?
"Any solution should support multiple transport layers,
but it is anticipated that this working group will focus on
a HTTP based solution. "
How would you change that statement?
The HTTP binding spec is separate from the protocol spec (core). I
would
suggest removing this section of the charter (it's another scenario):
I think we have to say there's going to be at least one transport... and
HTTP is the most obvious one. I could call out this piece of text so
that
it's clear that it applies to the HTTP transport binding.
Any solution should support multiple transport layers, but it is
anticipated that this working group will focus on a HTTP based
solution.
In this case the user's software is a web browser, to which no
modifications should be required, and the relying party would be a
website. Continuing with the theme of simplicity a website should
require
minimal changes to support identity information exchange. For
example, a
web form could receive information the same way that a user would
provide
it, as if they typed it into the form themselves.
In general I think this charter should be slimed down to the
essence of
digital identity exchange. Negotiation of authentication should be
part of
the solution offered by this group so I would remove or change the
following:
I think that it is. Are you asking for an in-scope statement to that
effect?
The mechanisms by which authentication and authorization are
performed.
To me negotiation and mechanism are different things. Perhaps we are
misunderstanding each other. For example:
Authentication Mechanism:
username / password
Authentication Negotiation:
HS to MS: 'I can authenticate using mechanisms: username-password, 2-
factor device, dna test'
MS to HS: 'Please authenticate the user with mechanism: 2-factor
device.'
Does that clarify that out of scope statement?
John
_______________________________________________
dix mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/dix
