Subject: [dix] Re: [Ietf-http-auth] BOF Request: WARP - Web Authentication Resistant to Phishing

From: John Merrells <[email-masked]>
Date: Thu, 1 Jun 2006 18:58:36 -0700

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-masked]
https://www1.ietf.org/mailman/listinfo/dix

---

From: Sam Hartman <[email-masked]>
Date: Fri, 02 Jun 2006 11:01:33 -0400

Hi, John.  Thanks for the new drafts.  I especially look forward to
the new use cases draft and will sit down to read that after finishing
this reply.

I do agree there is significant overlap; my interest in this area was
more or less directly motivated by the DIX bof and evaluating SXIP,
Infocard and other solutions for a talk I gave at a conference.

I think we view the requirements somewhat differently or at least view
what requirements need to be solved when somewhat differently.

I'm OK with a solution that supports situations where I have a single
alegidly unique identifier today but that can transition to more
complex forms of identity claims in the future.  You seem to want sets
of identity claims today.

I'm much more interested in reusing existing security technology and
am not interested in working on entirely new protocols.  (And I do see
this as a security problem which may also be a difference in how we
come at this.)

I consider requirements related to binding things together at multiple
levels (4.4 in my draft) really critical to forward progress on
phishing.  A lot of people disagree with me.  One on one I have been
able to convince people that I'm right, but the text in the current
section 4.4 clearly does not stand on its own and needs significant
revision.

Finally, I think it critical that whatever solution we have here needs
to work both with non-web HTTP applications (atompub, caldav, webdav,
deltav) and with non-HTTP applications.  I'd hate to see people pushed
towards HTTP as a substrate to get better identity management.

Needless to say my vision of the solution space is different because I
view these requirements differently.

I am working on a specific solution proposal to demonstrate that what
I want to do can be accomplished with incremental changes to existing
technology.

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Fri, 02 Jun 2006 16:51:51 -0400

>>>>> "John" == John Merrells <[email-masked]> writes:

    John> I'm not sure if you're saying this but... DIX does not
    John> impose any specific number of identifiers on a user. They
    John> can have as many as they choose to have, from 0 to infinity.

No, but dix does support transporting more than one claim and does
support claims that are not identifiers.

I don't view doing so as a requirement.

    >> but that can transition to more complex forms of identity
    >> claims in the future.  You seem to want sets of identity claims
    >> today.

    John> I find the 'claim' term to be a bit ambiguous, so try to
    John> avoid it.  I'm not sure how claims relate to identifiers in
    John> your comment above.

I use the terms claim, identity, subject and relying party as they are used in the Laws of Identity paper.

An identifier is a claim that is alegidly unique; email addresses are
viewed by some as identifiers.  Email addresses *are* the identifier
within the namespace of amazon.com identifiers as an example.

--Sam

---

From: Pete Rowley <[email-masked]>
Date: Fri, 02 Jun 2006 15:06:37 -0700

> I don't view doing so as a requirement.
It is a requirement if you require to support more than authN.  Access 
to a site might require an "I am over 21" token, authZ without direct 
authN - DIX supports that, and I believe it is important to do so.

-- 
Pete

---

From: John Merrells <[email-masked]>
Date: Fri, 2 Jun 2006 13:19:01 -0700

> what requirements need to be solved when somewhat differently.

Yes, that may well be the case. We're coming at this from a different
angle than you.

> alegidly unique identifier today

I'm not sure if you're saying this but... DIX does not impose any
specific number of identifiers on a user. They can have as many
as they choose to have, from 0 to infinity.

> but that can transition to more

I find the 'claim' term to be a bit ambiguous, so try to avoid it.  
I'm not
sure how claims relate to identifiers in your comment above.

The DIX protocol draft specifies how the an attribute value
assertion can be moved between parties... and the assertion
draft shows how those attribute value assertions could actually
be third party attested attribute value assertions.

The benefits are that websites that use common property names
will get more data of better quality and users won't have to deal
with tedious user registration forms.... And... if we can move
around third party assertions (Beth>21) then we have a safer
more productive internet.

> am not interested in working on entirely new protocols.

Well, we are too. Hence the reuse of SAML/HTML/HTTP/HMAC, etc.
We're just bringing the bits together in such a way that the barrier
to adoption (the really big problem) can be as low as possible.

> (And I do see

Yes, we're coming at this from a slightly different angle... not that
security isn't important, but we feel that we can provide real value
with just enough security... and show a roadmap of how people
can move up to more security when they need it.

> section 4.4 clearly does not stand on its own and needs significant

I agree with you.

> towards HTTP as a substrate to get better identity management.

I agree too.

I think the DIX messages could be mapped onto other protocols, or
pushed down into the stack. Our approach though has been to try
to avoid changing any code and any user behaviour. Not easy.

> view these requirements differently.

Yes.

> I want to do can be accomplished with incremental changes to existing

I'm looking forward to reading that. I hope you get buy in for  
solving the
secure user authentication problem.

John

---

From: Sam Hartman <[email-masked]>
Date: Sun, 04 Jun 2006 18:14:55 -0400

>>>>> "Pete" == Pete Rowley <[email-masked]> writes:

    Pete> It is a requirement if you require to support more than
    Pete> authN.  Access to a site might require an "I am over 21"
    Pete> token, authZ without direct authN - DIX supports that, and I
    Pete> believe it is important to do so.

I think the over-21 example is particularly bad because I cannot
imagine a site (at least in the US) not taking responsibility for that
check themselves based on demographic data they request.  It seems
like way too much of a risk to outsource this to an identity provider
especially if you allow identities from a number of different identity
providers.

However I do agree that non-identifier claims are something we want to
support in the fullness of time.  I just think that we can learn a lot
by getting something that supports a single identifier claim in the
first version.  I don't even mind if we standardize more than that, I
just question whether it needs to be mandatory to implement.

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 04 Jun 2006 15:35:49 -0700

> especially if you allow identities from a number of different identity

I'm surprised to see you make this claim, since outsourced
adult verification services for porn sites are extremely common.

http://en.wikipedia.org/wiki/Adult_Verification_System

-Ekr

---

From: John Merrells <[email-masked]>
Date: Sun, 4 Jun 2006 16:16:43 -0700

On 4-Jun-06, at 3:14 PM, Sam Hartman wrote:

> first version.

Not thinking through all the issues leads to solutions that can't be
built upon. Note that OpenID can move an 'identifier claim'... but
can't move other claims... because it wasn't part of the design
requirements.

John

---

From: Johannes Ernst <[email-masked]>
Date: Sun, 4 Jun 2006 16:59:57 -0700

> can't move other claims... because it wasn't part of the design

Sure you don't mean to imply that nobody can build on OpenID? Today,  
there are working and deployed OpenID-enabled identity providers that do
  - VCard data exchange
  - social network data exchange
  - registration data exchange
  - authenticated messaging
and there a number in the labs that add a fairly impressive set of  
other capabilities ranging from location-based services to social  
media and e-commerce enablement. (And that's just the ones I know  
about.)

On top of OpenID, no problem whatsoever.

You are entirely right that OpenID's initial requirements were only  
about proving that a browser session was owned by somebody who had  
control over a certain URL. However, in conjunction with the Yadis  
discovery and composition framework, it has become a very  
"composable" piece of technology since last fall; for example, at  
NetMesh we are running all LID services on top of OpenID  
authentication just as well as on top of LID's original GPG-based  
authentication. A number of other companies have built on top as well  
with new services that meet their customer's needs.

Let's not mistake orthogonality for limitation when looking at designs.

I don't want to take this thread off subject from "WARP - Web  
Authentication Resistant to Phishing" -- I just thought I need to put  
the record straight here.

Johannes Ernst
NetMesh Inc.

  http://netmesh.info/jernst

---

From: John Merrells <[email-masked]>
Date: Sun, 4 Jun 2006 20:41:15 -0700

> Let's not mistake orthogonality for limitation when looking at  

Yes, and let's not confuse flaws with features.

If OpenID could move attribute value assertions we'd all be better off.

John

---

From: Sam Hartman <[email-masked]>
Date: Mon, 05 Jun 2006 17:00:41 -0400

>>>>> "Eric" == Eric Rescorla <[email-masked]> writes:

    >>  I think the over-21 example is particularly bad because I
    >> cannot imagine a site (at least in the US) not taking
    >> responsibility for that check themselves based on demographic
    >> data they request.  It seems like way too much of a risk to
    >> outsource this to an identity provider especially if you allow
    >> identities from a number of different identity providers.

    Eric> I'm surprised to see you make this claim, since outsourced
    Eric> adult verification services for porn sites are extremely
    Eric> common.

My point is that I expect the porn site to have a contract with some
verification service they trust and not to want to handle that data
transport through the identity exchange.

---

From: John Merrells <[email-masked]>
Date: Mon, 5 Jun 2006 14:07:07 -0700

On 5-Jun-06, at 2:00 PM, Sam Hartman wrote:

> verification service they trust

They would in both cases. They 'trust' the authority, and they need
a mechanism to verify the claim.

> and not to want to handle that data

Why not? It costs less to implement. The Service Provider just has
to state up front what it's policy is wrt to the set of claims it  
requires
to permit access to the requested content. The claims are some
kind of signed blob (eg SAML assertion)... why would they care if
it came in with the user's 'login' to the site?

John

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 05 Jun 2006 14:19:45 -0700

> transport through the identity exchange.

I'm not sure I see the distinction here.

As I mentioned at the DIX BOF in Dallas, there are two kinds of claim
that one could imagine an identity provider making:

1. Claims for which they are authoritative (like when rtfm.com's
   name server asserts that www.rtfm.com has a certain IP address)
2. Claims for which it's not authoritative but which have some
   independent truth value (e.g., this person is over 21, has
   the following SSN, etc.)

Any system which allows for the second kind of claim must by
necessity involve the relying party having some trust in the 
provider making the assertion (as opposed to the first in 
which you simply need to verify who they are). No? In what
way couldn't that apply to an "identity exchange"?

I'm also not sure that I understand your point about a "contract".
After all, we routinely trust physical (drivers licenses)
and electronic (SSL certs) credentials from organizations
with which we have no prior relationship. The reason for there
to be a contract betwen the porn site and the AVS isn't really
so that the porn site can trust the AVS but rather so that
money can flow. [1]  In the absence of that money flow 
(or the presence of a direct money flow like in the case
where you show ID to buy alcohol) then it's not clear to
me that the relying party needs a contract with the AVS.

-Ekr

[1] Incidentally, the way the money flows here is generally from
the AVS to the porn site. Effectively, the AVS is charging
you for accessing the site.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 05 Jun 2006 17:23:26 -0400

>> >> I think the over-21 example is particularly bad because I >>
    >> cannot imagine a site (at least in the US) not taking >>
    >> >> outsource this to an identity provider especially if you
    >> allow >> identities from a number of different identity
    >> providers.
    >> 
    >>  My point is that I expect the porn site to have a contract
    >> with some verification service they trust and not to want to
    >> handle that data transport through the identity exchange.

    Eric> I'm not sure I see the distinction here.

The distinction is layer 9; I don't think there is a technical distincition.

It is my impression mostly from financial sector businesses that you
are going to see people verifying this information themselves (through
a separate exchange with a business partner) rather than trusting the
same assertion signed as part of the identity exchange.

--Sam

---

From: John Merrells <[email-masked]>
Date: Mon, 5 Jun 2006 14:37:17 -0700

> same assertion signed as part of the identity exchange.

It doesn't have to be the same assertion. There can be multiple
assertions each signed by different authorities.

The IdP may have authority for identifying and authenticating the
person... but the other assertions that come in the exchange could
be issued by other authorities. This is why in DIX we have the
separation between the acquisition of an assertion and the
presentation of an assertion. And why the Fetch message
allows for the combination of a request for an authentication
assertion with the request for attribute assertions... all with
different signers.

The user can then collect claims from whatever authorities
they chose, before an exchange, or upon demand. The Relying
Party then only needs to trust the Authority of the claim rather
than where the claim is coming from.

John

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 05 Jun 2006 14:42:31 -0700

> same assertion signed as part of the identity exchange.

I'm still not sure I get what you're saying. Let me see if I can
try again looking at the flows of data.

OPTION 1: What I take DIX to be doing

Client                     IdP                   Relying Party

-------------------------  Service Please ------------>
<------------------------- Prove you're over 21--------

<-------Auth exchange ------>
<------- Over 21 credential--

<----------------- Auth exchange plus over 21 cred ---->

OPTION 2: What I think you're describing

Client        IdP            Relying Party       Business partner
----------  Service Please ------------>
<---------  Prove your identity --------

<-- Auth exch --
<---Id cred ----

<------ Auth exchange plus Id cred ---->
                                  
                                   --- User's ID -->
                                   <-- Over 21 -----

Do I have this correct?

-Ekr

---

From: John Merrells <[email-masked]>
Date: Mon, 5 Jun 2006 14:57:01 -0700

> OPTION 1: What I take DIX to be doing

Yes, this interaction diagram is correct.

> <----------------- Auth exchange plus over 21 cred ---->

Assuming that at some point earlier the user acquired an over 21  
assertion
from an appropriate authority.

Client            Identity Agent                   Authority

-------------------------  Service Please ------------>
<--- Auth/Verify exchange, maybe even out of band ---->
<------- Over 21 credential----------------------------
<--------- Over 21 cred ---->

John

---

From: Sam Hartman <[email-masked]>
Date: Mon, 05 Jun 2006 19:04:47 -0400

Yes, your understanding is correct.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 05 Jun 2006 16:28:52 -0700

> Yes, your understanding is correct.

Good. Then we have a basis to talk about them.

So, for reference here's my summary of the schemes in text form:

    The way that DIX works is that you authenticate to the IDP which
    hands you some credential which attests to some set of assertions
    about you. In this case, said credential would contain the claim
    that you were over 21. You'd then provide the credential to the
    relying party.
    
    In the scheme Sam is describing you would authenticate to the
    relying party, possible using something like DIX, but with some
    scheme that gave the relying party your actual identity (true
    name, SSN, drivers' license #, whatever). The relying party would
    then independently contact some authority it trusted to find out
    what it wanted to know (e.g., if you're over 21).

With respect to your original argument that relying parties will want
to have contractual arrangements with the third party authorities
they're getting information from, I certainly agree that that's true
in many cases, such as background checks, taxes, etc., where the
databases are all keyed by some sort of individual identifier (name,
phone number, driver's license number, SSN/TIN, etc.).

However,there are also many cases where it's untrue, with the most
obvious being the use of state-issued photographic ID for various
kinds of identification and age verification purposes.  When a bar
checks my ID before serving, they're not relying on any
contract between them and the state of California.[0] So, I don't think
it's really accurate to say that asserting claims along the identify
exchange path isn't something that people are going to want to do in
general. 

Moreover, true-name based systems like the one you describe have
quite poor privacy properties:

(1) it means handing out your true name all over the place.
(2) you have very little control or even visibility into 
    what the third party gives to the relying party.
(3) the third party tends to collect a lot of information
    about your activities as a matter of course.

So, a system in which you could individually assert individual claims
without exposing a bunch of irrelevant but sensitive information would
have some advantages from a privacy perspective. I absolutely agree
with you that there are settings in which relying parties will
want to get your identity and then use that for their own research
obviously if one designs a system without independently assertable
claims of this kind, then that will be the only thing they can do,
which seems like a bug.

-Ekr

[0] Yes, I realize that some states do license bars, but consider
the case of out-of-state or Federal ID if you want to be picky.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 05 Jun 2006 20:22:16 -0400

>> Yes, your understanding is correct.

    Eric> Good. Then we have a basis to talk about them.

I basically agree with the general statements you have made.  I
believe that the specific example of age verification on the web will
tend not to fall into the case where people use independently asserted
idenity claims especially in the medium future.  I don't have high
confidence in that belief though and I don't think it matters much
whether I'm right or not.  We both agree that there will be third
party claims.

As I've said before I think that whatever we design needs to
eventually support claims and third party claims.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 05 Jun 2006 17:27:50 -0700

> eventually support claims and third party claims.

I think there's a missing part to this statement: if you plan to
support third party claims, I think there's a pretty strong argument
that such claims need to be independently assertable.

-Ekr

---

From: "Ben Laurie" <[email-masked]>
Date: Tue, 6 Jun 2006 03:10:28 +0100

> same assertion signed as part of the identity exchange.

Hmmm. I see people trusting client certs (in the financial sector, as
it happens), so I can't say I agree that this is by any means
universal.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 06 Jun 2006 07:24:28 -0400

>>  I basically agree with the general statements you have made.
    >> I believe that the specific example of age verification on the
    >> web will tend not to fall into the case where people use
    >> independently asserted idenity claims especially in the medium
    >> future.  I don't have high confidence in that belief though and
    >> I don't think it matters much whether I'm right or not.  We
    >> both agree that there will be third party claims.
    >> 

    Eric> I think there's a missing part to this statement: if you
    Eric> plan to support third party claims, I think there's a pretty
    Eric> strong argument that such claims need to be independently
    Eric> assertable.

Agreed.

---

From: "Haripriya S" <[email-masked]>
Date: Wed, 07 Jun 2006 06:11:43 -0600

John,

Looking at the last diagram, and the discussion on keeping the
acquisition of assertions separate from presenting those, I have this
basic question (could also be due to my lack of knowledge of SAML
assertions :-)):

When a user needs to present the identity assertion, and the "over 21
assertion" from the ID agent, what prevents a man-in-the-middle from
mixing and matching assertions? Example: What if I have browser code to
take my ID assertion from the ID agent, and someone else's "Over 21"
assertion (which I probably captured by posing as a replying party), and
passed it on to the replying party. Is this scenario possible? Is there
a restriction on who can present an assertion in the assertion itself? 

Thanks and Regards,
Haripriya S.

>>> John Merrells <[email-masked]> 06/06/06 3:27 am >>> 

> Client                     IdP                   Relying Party
>
> -------------------------   Service Please ------------ >
> <------- Auth exchange ------ >
> <-----------------  Auth exchange plus over 21 cred ---- >

-------------------------   Service Please ------------ >
<---  Auth/Verify exchange, maybe even out of band ---- >
<-------  Over 21 credential----------------------------
<---------  Over 21 cred ---- >

John

---

From: "Ben Laurie" <[email-masked]>
Date: Wed, 7 Jun 2006 13:15:57 +0100

> a restriction on who can present an assertion in the assertion itself?

I think you mean "relying" rather than "replying". And certainly it
can be arranged that a man in the middle cannot present it - for
example, you could have the owner sign the assertion (and have that
signature signed by the issuer of the assertion) and then require them
to prove ownership of the signing key when presenting the assertion.