BOF proposal: making the web safe and easy for Eliot's father

Sam: great to see you looking to make the web safe and easy!
... some  
comments inserted below ...

On 16-May-06, at 7:59 AM, Sam Hartman wrote:
> Initially I'm talking about binding an identifier to a
session; if you
> will asserting the identity claim that hartmansmit.edu
uniquely
> applies to the subject of the session.

This is one of the use cases of DIX.

>
> I think that long term, protocols will need to scale to
support
> additional claims.  One of my main disagreements with
the dix effort
> is over whether the complexity associated with managing
the privacy of
> claims and standardizing claims is a good thing to
include in the
> first phase of the solution.

Would you elaborate more about what you think is complex?

I think that if it is to scale to support additional claims,
 
standardized claims are necessary.

> I'm sure that many identity providers will make claims
such as name
> available.  It's not clear to me that needs to be
happening in the
> same place as we handle authentication to the website
until we get to
> a point where we start supporting sending an identity
to the website
> that is not unique.  Only at that point does the
identity claim set
> need to be part of the authentication

I see authentication as proving I am a particular entity
again.

An identity claim (using your term) lets the site know I
have a  
particular property, assuming the site trusts who made the
identity  
claim.

-- Dick
_______________________________________________
Ietf-http-auth mailing list
Ietf-http-authosafoundation.org
http://lists.osafoundation.org/cgi-bin/mai
lman/listinfo/ietf-http-auth

>>>>> "Dick" == Dick Hardt
<dicksxip.com> writes:

    Dick> Sam: great to see you looking to make the web
safe and easy!
    Dick> ... some comments inserted below ...

    Dick> On 16-May-06, at 7:59 AM, Sam Hartman wrote:
    >> Initially I'm talking about binding an
identifier to a session;
    >> if you will asserting the identity claim that
hartmansmit.edu
    >> uniquely applies to the subject of the session.

    Dick> This is one of the use cases of DIX.

Yes.  But I don't think dix meets anti-phishing
requirements that I
think are critical.

I'd rather focus on a strong solution to phishing
requirements and the
Eliot's dad problem.  If it happens to meet other use cases
of dix,
that would be great too.


    >>  I think that long term, protocols will need to
scale to
    >> support additional claims.  One of my main
disagreements with
    >> the dix effort is over whether the complexity
associated with
    >> managing the privacy of claims and
standardizing claims is a
    >> good thing to include in the first phase of the
solution.

    Dick> Would you elaborate more about what you think
is complex?

I think that designing a UI that allows people to express
privacy
preferences and handle phishing issues will be really hard. 
I'd
rather focus on the phishing problem first and then possibly
later
work on additional identity claims and privacy preferences.

    Dick> I think that if it is to scale to support
additional claims,
    Dick> standardized claims are necessary.

Agreed.  I think that when you add support for additional
claims you
need to also standardize claims.  My argument is simply that
solving
the problem of binding a unique identifier of the subject to
the
session in a manner that resists phishing is a hard enough
problem.
If it turns out we can do more, that's great.

    >> I'm sure that many identity providers will
make claims such as
    >> name available.  It's not clear to me that
needs to be
    >> happening in the same place as we handle
authentication to the
    >> website until we get to a point where we start
supporting
    >> sending an identity to the website that is not
unique.  Only at
    >> that point does the identity claim set need to
be part of the
    >> authentication

    Dick> I see authentication as proving I am a
particular entity
    Dick> again.

    Dick> An identity claim (using your term) lets the
site know I
    Dick> have a particular property, assuming the site
trusts who
    Dick> made the identity claim.


Most of the schemes under discussion have at least a
notional third
party which is the identity provider.  You authenticate to
the
identity provider.  How you do that is mostly out of scope
except that
we need to standardize strong mechanisms for doing that and
make one
of them mandatory to implement.

But there is also an authentication protocol carried out
between the
identity provider and the relying party.  The identity
provider makes
an authenticated assertion of various claims of identity. 
This
protocol needs to have various properties to avoid phishing
attacks.
One of them is that the relying party must not receieve
enough
cryptographic information to make what appears to be an
authenticated
assertion of identity from the original identity provider to
the third
party.

_______________________________________________
Ietf-http-auth mailing list
Ietf-http-authosafoundation.org
http://lists.osafoundation.org/cgi-bin/mai
lman/listinfo/ietf-http-auth