Hello Sam,
I read your webauth-phishing draft. I thought it explored the phishing
problem space really well.
Your BOF request below seems to go further in scope though and
overlaps with what the DIX group have been working on. I'm going
to work through your text calling out the bits where the scope of DIX
and WARP appear to overlap.
[A quick aside. I just published some updated DIX drafts today...
Use Cases, Protocol, and Assertion. They're all available here:
http://dixs.org/index.php/DIX_Protocol_Internet_Drafts]
On 23-May-06, at 2:34 PM, Sam Hartman wrote:
WARP is chartered to develop a method for using existing
authentication technology to address two critical problems with
authentication for the web and other HTTP-using applications.
This is a good thing. With DIX we chose for the actual authentication
of the user to be out of scope. We just focused on how the resultant
authentication assertion would be moved from the Identity Provider
to the Relying Party. (To use SAML terminology.)
The
first problem is that users must remember and maintain passwords
for each HTTP service they use.
The way I'm reading this I think this goes beyond the scope of
authenticating
the user... perhaps towards identifying the user. In DIX we enable
third-party
authentication and identify the user with an identifier (a URI...
typically a URL).
The second problem is that of
phishing. While browser UIs must change in order to combat the
problem of phishing, WARP must work with these UI changes and must
provide clear technical requirements for the security features
needed from authentication UI.
Is this in the scope of the IETF though... to provide UI requirements...
to be met by the W3C?
WARP will attack the problem of multiple passwords in two ways.
First, it will be safe from a security standpoint to use the same
password with multiple HTTP services. Second, WARP will support
the concept of an identity provider, which is a service that
clients can authenticate to and that can make assertions about
their identity to third parties.
In DIX we term this the Identity Agent, which can be a Website or
an Application.
What kinds of 'assertions about identity' do you mean? I'd assumed
your identity provider would only be generating authentication
assertions. In DIX we support both self asserted and third-party
attribute value assertions. Note that that's not just from the Identity
Provider, but from other Service Providers authoritative for some
attribute of the user.
And to what kinds of third parties? Thus far I'd assumed that the
only parties involved were the User Agent and the Identity Provider.
I think these are the 'HTTP services' above. Which in DIX is a
Service Provider that consumes the attributes and assertions from
the Identity Agent. Is this what you mean? This bit clearly overlaps
with DIX.
Employers authenticating their
employees to business partners, distributed communities that share
a concept of identity and services like Microsoft's Passport
service
demonstrate the wide variety of identity providers. There will
never be a single identity that a user can use on the web: many
users would not choose to use the same identity in a work context
that they use personally; similarly business relationships and
policies will dictate what identities services can accept.
However WARP will support the concept of identity providers so
that when policies permit, users can minimize the number of
identities they use. WARP must support identity providers
associated with servers and should support identity providers that
have relationships with users.
This sounds very much like DIX, and Identity 2.0 in general... but
doesn't cover all of Kim's Laws of Identity. You could just reference
that, but I'm concerned you're trying to take on the whole thing,
rather than just tackling a more secure way of authenticating the
user.
WARP needs to support mobile users,
'Mobile' equals 'cell phone' to me... a european thing perhaps.
Maybe there's a better word, but I can't think of one.
including users that use
HTTP services from computers they have never used before. WARP
must not require per-service or per-identity-provider
configuration.
I don't understand that statement. WARP can be deployed without
changing any service or IdP code/configuration?
While WARP is focused on passwords as that is
expected to be the primary means of authentication, WARP needs
to support other credentials including smart cards, one-time
passwords and zero-knowledge password protocols.
That's all good.
It is
desirable that WARP be able to carry assertions about identity such
as Security Assertion Markup Language assertions.
But, is this DIX again. What are the assertions about and where are
the coming from and going to. I'm suspecting they're any assertion and
they're coming from the IdP to the SP. DIX covers that with more
flexibility... in that roles of the IdP are separated out.
The WARP working group will first write a problem statement and a
requirements draft describing what it means to produce an
authentication solution that is resistant to phishing. Then WARP
will choose a mandatory-to-implement authentication technology
That's good.
and
protocol for the interaction between the identity provider and
website.
I think this is DIX...
WARP will coordinate with W3C in working on the UI
implications of
phishing. WARP will not propose specific UI nor specific
extensions to HTML, although WARP may recommend requirements for
both as these requirements directly impact the security or
deployability of WARP.
I'm not sure how this will work in practice. I'd image the W3C would
want to define their own UI/HTML requirements... but I'm sure they'd
welcome input if the group generates some requirements as a
side-effect of the work.
Deliverables:
* Problem statement for WARP
* Requirements for authentication resistant to phishing
* WARP protocol document describing how an existing authentication
system is used to meet the requirements of WARP. This document
may specify mandatory to implement modes in addition to those
specified in the underlying system.
I read this as WARP does 'authentication resistant to phishing', and
I don't think that covers a protocol from the identity provider to the
website.
* A proposed standard describing how an identity is registered with
an identity provider or website.
What does that mean? Maybe I just need more detail. But why an
'or' in 'identity provider or website'...
In DIX a User Identifier is either assigned by the Identity Agent, or
the user delegates authentication of an existing URL to an Identity
Agent. And a Service Provider has a range of options over whether
the User needs to identify themselves or not. There are privacy
benefits to the SP being able to offer a service without actually
having to create an 'account'.
* A proposed standard describing how an identity associated with a
user is linked to an HTTP service's concept of an account.
Sounds much like the 'or website' bit above. But again... DIX
does this... and is set up so that you don't need to.
In summary:
I think there's lots of value in WARP for dealing with authentication
of the user to the identity provider... but if you go beyond that from
the identity provider to the website then you're coving the scope
of DIX... which in-my-not-so-humble-opinion has thought through
and dealt with all these issues already and more besides.
I think that if the scope of the work can be tightened up and there
are people interested in working on this that it'll be a great
complement to the DIX work.
John
_______________________________________________
dix mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dix
