Subject: [Sipping] RE: Network Asserted Identity

From: "Mark Watson"<[email-masked]>
Date: Thu, 18 Apr 2002 15:12:19 +0100

So, no comments on the proposed requirements below. I take it everyone
agrees then ?

...Mark

> -----Original Message-----

> OK, so lets see if we can conclude on _short-term_ Network 
> Asserted identity requirements in a separate thread. 
> Follow-ups to SIPPING ONLY please.
> 
> First, assume a trust domain model as per privacy draft 
> applicability statement. Entities within a domain trust each 
> other, entities in different domains are mutually untrusted.
> 
> I'll try to build up the requirements, least contraversial first: 
> NAI1) The ability for network entities to insert a network 
> asserted identity and pass to other network entities within 
> the same trust domain.
> 
> NAI2) The ability for a network entity to pass a 
> (non-private) network asserted identity directly to a UA
>
> NAI3) Secure transport of network asserted identity across 
> 'untrusted' networks back to the same trust domain (including 
> between trust 'islands' - disconnected parts of a single trust domain)
> 
> NAI4) Transport of network asserted identity between trust 
> domains (i.e. transport in one domain of a network asserted 
> identity received from another domain)
> 
> For clarity, 
> (a) the requirement for a user to choose one of a number of 
> identities, whilst retaining privacy, is a 3GPP requirement, 
> but is *out of scope* of this thread.
> 
> (b) Call Trace implemented by encrypting the identity and 
> passing this to the called user, who can then pass the 
> encrypted identity to the generating service 
> provider/authorities, is considered a sub-case of NAI3 - the 
> identity is passed to the 'untrusted' user and back to the 
> original Trust Domain (the Service Provider) before being 
> passed to the authorities.
> 
> I expect the From/To debate will continue, probably to the 
> end of time, but I don't see a strong relationship with this issue.
> 
> If people agree with my statement of the potential 
> requirements, perhaps we could open discussion on which of 
> these should be considered for immediate standardisation. The 
> others can be put into the pot for discussion of the generic 
> privacy requirements.
> 
> For my part, I am most concerned about NAI1 and NAI2. 
> 
> Regards...Mark 
> 
> > -----Original Message----- 
> > From: David R. Oran [mailto:[email-masked]] 
> > Sent: 15 April 2002 17:39 
> > To: 'Rosen, Brian'; [email-masked]; [email-masked] 
> > Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft 
> > 
> > 
> > Brian Rosen wrote: 
> > >If we could get consensus that trace-with-anonymity is the 
> problem, 
> > then > we can 
> > > work on solutions.  Until we get to something as 
> straightforward as 
> > > that, 
> > > we are going to spin a lot of wheels. 
> > 
> > That's always been the prime motivator for me, plus the 
> > secondary use of 
> > NAI for call return to an anonymous caller. 
> > 
> > Dave 
> > 
> > 
> > _______________________________________________ 
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip 
> > This list is for NEW development of the core SIP Protocol 
> > Use [email-masked] for questions on current sip 
> > Use [email-masked] for new developments on the application of sip 
> > 
> 
> ---
> Mark Watson
> UMTS Strategic Product Planning
> Nortel Networks, Maidenhead, UK
> Tel: +44 1628 434456 email: [email-masked]
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 18 Apr 2002 13:35:50 -0400

> (non-private) network asserted identity directly to a UA  
I'd like to explore this one.  In my zeal to cut down the discussion to 
manageable hunks, I don't get why we need this now.  I think NAI is 
strictly for SP elements to assert an identity to one another, 
and there is no requirement for any UA to see it.  If we can always 
define NAI as inserted by the network, and stripped prior to sending to 
a UA, then I think many things may get simpler.

It may also make other people happier with this work - UAs send 
things they want the other UA to see.  Proxy Servers send things 
they want other Proxy Servers to see.  I'm still assuming a B2BUA 
is needed for really anonymous calls, and to deal with Subscriber 
vs User issues. 

Brian

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Zmolek, Andrew (Andrew)" <[email-masked]>
Date: Thu, 18 Apr 2002 12:25:53 -0600

While enterprise customers in general probably don't care so much if NAI is passed directly to the UA or handled by an intermediary they own/manage, I would like to encourage the SIP community to recognize that either: (1) Enterprises can be their own "service providers" in every sense (with or without others) or alternatively: (2) another term is needed to represent the broader notion of all regulated and unregulated, private or public providers of SIP services. 

Many enterprise call centers today make use of this information. I can imagine scenarios where an authorized UA might receive NAI information but if the answer is that it doesn't go beyond some class of proxy or other intermediary I suppose that's a fine answer provided that the notion of "service provider" is properly defined.

If somehow our NAI standard required the kind of formalism that today is reserved for carrier-to-carrier interchange, then that would be a bad thing.

--Andy

> From: Rosen, Brian [mailto:[email-masked]]
> Sent: Thursday, April 18, 2002 11:36 AM
> To: 'Mark Watson'; [email-masked]'
> Subject: RE: [Sipping] RE: Network Asserted Identity
> 
>

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 18 Apr 2002 13:29:41 -0500

Well, a few comments on this, actually. First, we might quibble over some of
the terminology here: 'network entity', what these 'identities' represent,
etc.
 
Next, I think most of the problems with sip-privacy-04 seem to fall out from
the fact that the concepts of 'trusted' and 'untrusted' are not well
understood. I'm not sure that we can use these words and think that we're
actually putting forward a hard requirement. The Iraqi example, 'screen' and
so forth exposed some of the problems with these terms. Therefore I'm a
little wary of NAI1, NAI3 and NAI4. NAI3 and NAI4 especially seem to make
assumptions about how trust operates that are a little silly. For NAI3, why
would a SIP 'trusted' domain send something through an untrusted domain to
get back to itself, to the same trusted domain? Sure, in the PSTN that might
make sense, but that would be a harder sell to claim that SIP networks will
need to do this. The whole concept of a trusted domain would require
significant explication before any of this made sense. In sip-privacy-04,
perhaps the biggest problem is that 'trustedness' is assumed to be something
intrinsic about an entity, rather than something about which every other SIP
element in the world is entitled to its own opinion.
 
I would rather phrase NAI1 and NAI2 a little differently. Ideally, these
should only be one requirement - that a 'network entity' can insert the
identity of a user into a message, and that this identity can be viewed by
the recipients of the message. It is a separate matter, a privacy
requirement (which I surmise you don't want to group with NAI requirements),
that in some instances the user can request that their identity not be
shared with others, and it is a problem for that requirement that some
administrative domains might obstinantly be inclined to circulate the user's
identity anyway. Without this privacy requirement, NAI1 and NAI2 would be
identical, right? NAI4, I suspect, is also this same requirement, in any
definition of 'trust' that will turn out to be usable.
 
On clarifying remark (a), I've never been sure what the big deal is about
this 'hinted' identity. I consider 'hinting' to be part of the
authentication process by which the NAI is generated. If someone would like
to propose some new authentication scheme for SIP that contains a plaintext
'hinted' identity in a header that is sent in a request to the entity that
generates the NAI (assuming that some other part of the authentication
process involving security has already occurred, or is occurring out of band
but cannot accomodate the 'hint'), I welcome them to do so - whether or not
any IETF working group would look favorably on that is a different matter.
In any event, I maintain that this is a question about how authentication
works, and it is orthogonal to the NAI problem - it just ended up being
conflated with the privacy and identity problems in the initial
considerations of this space. We can all think of authentication systems
that intrinsically support such a hint (like Digest, which is mandatory for
all SIP entitites).
 
Clarifying remark (b) makes NAI3 a little more practical, but I think I read
NAI3 very differently (in that it didn't involve some sort of administrative
process, but was just a protocol concept). I believe (b) is different enough
to be a requirement in its own merit, though it also is probably not
uncontroversial.
 
So even with a short-term view, I'm afraid I can't immediately go along with
these.
 
Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: Mark Watson [mailto:[email-masked]]
Sent: Thursday, April 18, 2002 7:12 AM
To: [email-masked]'
Subject: [Sipping] RE: Network Asserted Identity

...Mark 

> > From: David R. Oran [ mailto:[email-masked] <mailto:[email-masked]> ] 
<https://www1.ietf.org/mailman/listinfo/sip>

---

From: [email-masked]
Date: Thu, 18 Apr 2002 15:39:45 EDT

> > but is *out of scope* of this thread. 

The question still remains - what is "user" in the above statement. When I 
log into AOL (yea, I know, bad idea) I can specify one of several identities 
(screen name). If I had a SIP phone, it would likely be capable of multiple 
identities that I personally might use or someone else would use. So there is 
clearly a requirement for the "User Agent" (the device) to choose one of a 
number of identities. I believe there is also a clear need for the "user" 
(person) to choose one of a number of identies. So why is this not a 
requirement, other than for 3GPP? Note that my above statements are not 
directly addressing "privacy", but just the "identity" part of the issue. The 
requirements for choosing privacy should be the same.

Mike

---

From: "Mark Watson"<[email-masked]>
Date: Fri, 19 Apr 2002 16:45:11 +0100

Either - I'm just saying terminating services will work more reliably if the
information they work on is more reliable.

...Mark

> From: Juha Heinanen [mailto:[email-masked]]
> Sent: 19 April 2002 13:49
> To: Watson, Mark [MDN05:EP10:EXCH]
> Cc: 'Rosen, Brian'; [email-masked]'
> Mark Watson writes:
>  > Many services based on the identity of the caller will 
> operate much more
>  > sucessfully based on the network asserted identity that 
> just based on the
>  > caller's claimed identity.
> 
> i'm a bit confused by what "identity" means here: the identify of the
> user, e.g., [email-masked], or the from uri, e.g., tel:+35844123456, the
> user wants to use in the call.
> 
> -- juha
> 
>

---

From: "Mark Watson"<[email-masked]>
Date: Fri, 19 Apr 2002 18:05:32 +0100

Jon,

I was trying to keep things simply stated, assuming that everyone understood
the applicability statement in the privacy draft - well, at least everyone
that was involved in writing it.

Just for you, in terms of 'significant explication', there is a mathematical
definition of a 'Trust Domain' at the end of this mail along with the
proposed requirements. I think the previous statement of requirements was
clearer, but at least the one below is well-defined.

For everyone else, a 'Trust Domain' is just a group of SIP devices which are
known to follow a particular set of specifications with respect to identity.
One device in the domain 'trusts' another if it has a secure connection to
it AND has been *configured* with the information that the other device is
in the same Trust Domain.

I am proposing that we adopt NAI1 and NAI2 only, which I believe aligns with
Rohan's plan and the 3GPP requirements.

Pls see comments below.

...Mark

Jon wrote:
> Next, I think most of the problems with sip-privacy-04 seem 
> to fall out from the fact that the concepts of 'trusted' and 
> 'untrusted' are not well understood. 

Please see above.

> I'm not sure that we can 
> use these words and think that we're actually putting forward 
> a hard requirement. The Iraqi example, 'screen' and so forth 
> exposed some of the problems with these terms. Therefore I'm 
> a little wary of NAI1, NAI3 and NAI4. 

The Iraqi example concerned NAI4 only. I am not proposing we adopt this
requirement. I'm not sure how that example has relevant to NAI1 and NAI2.

> NAI3 and NAI4 
> especially seem to make assumptions about how trust operates 
> that are a little silly. For NAI3, why would a SIP 'trusted' 
> domain send something through an untrusted domain to get back 
> to itself, to the same trusted domain? 

Because the Trust Domain is not a fully connected network. There are
elements which are not interconnected by any path through trusted elements,
and so the only way of passing information between them is via untrusted
parts of the network. One solution would be to encrypt the information using
a key known to all elements in the Trust Domain. It also encompasses the
Call Trace solution where the user is given the encrypted NAI and passes it
back to (the owner of) the Trust Domain.

If we don't have this requirement, then we don't need encryption.

I am not proposing we adopt this requirement.

> Sure, in the PSTN that 
> might make sense, but that would be a harder sell to claim 
> that SIP networks will need to do this. The whole concept of 
> a trusted domain would require significant explication before 
> any of this made sense. In sip-privacy-04, perhaps the 
> biggest problem is that 'trustedness' is assumed to be 
> something intrinsic about an entity, rather than something 
> about which every other SIP element in the world is entitled 
> to its own opinion.

I don't think the assumption you claim is made by the draft. 'Trustedness'
is indeed an 'opinion' that one node has about another, based on
configuration by human beings who know the properties of the devices (i.e.
that they are indeed compliant to the relevant specifications and so can be
trusted to act in a particular way).

>  
> I would rather phrase NAI1 and NAI2 a little differently. 
> Ideally, these should only be one requirement - that a 
> 'network entity' can insert the identity of a user into a 
> message, and that this identity can be viewed by the 
> recipients of the message. It is a separate matter, a privacy 
> requirement (which I surmise you don't want to group with NAI 
> requirements), that in some instances the user can request 
> that their identity not be shared with others, and it is a 
> problem for that requirement that some administrative domains 
> might obstinantly be inclined to circulate the user's 
> identity anyway. Without this privacy requirement, NAI1 and 
> NAI2 would be identical, right?

No. The requirements do not mention privacy.

NAI1 and NAI2 do ask for different things. There is certainly a way of
stating a single requirement which covers both, but I separated them in case
we don't *want* both.

> NAI4, I suspect, is also this 
> same requirement, in any definition of 'trust' that will turn 
> out to be usable.
>

No. NAI4 implies the need for 'screen' or something equivalent. Without NAI4
then it can be assumed that Network Asserted Identities passed between
entities of a Trust Domain were asserted by an entity in the same Trust
Domain. NAI4 allows identities that were asserted by another Trust Domain to
be passed around. This includes those asserted by a Trust Domain containing
a single User Agent which is exactly what causes the problem of
distinguishing between the identity asserted by the Iraqi network and an
identity asserted by some mischevious user.
 
> On clarifying remark (a), I've never been sure what the big 
> deal is about this 'hinted' identity. I consider 'hinting' to 
> be part of the authentication process by which the NAI is 
> generated. If someone would like to propose some new 
> authentication scheme for SIP that contains a plaintext 
> 'hinted' identity in a header that is sent in a request to 
> the entity that generates the NAI (assuming that some other 
> part of the authentication process involving security has 
> already occurred, or is occurring out of band but cannot 
> accomodate the 'hint'), I welcome them to do so - whether or 
> not any IETF working group would look favorably on that is a 
> different matter. In any event, I maintain that this is a 
> question about how authentication works, and it is orthogonal 
> to the NAI problem - it just ended up being conflated with 
> the privacy and identity problems in the initial 
> considerations of this space. We can all think of 
> authentication systems that intrinsically support such a hint 
> (like Digest, which is mandatory for all SIP entitites).

Agreed. That is why I left it out of scope of this thread.

The requirement is specific to scenarios where a single user (from an
authentication point of view) can be identified by several URIs. This is
certainly the case in 3GPP, and I would expect in other networks.

3GPP have the additional restriction that, except at registration,
authentication is achieved by non-SIP means. So, some means other than SIP
authentication is needed for this hint.

>  
> Clarifying remark (b) makes NAI3 a little more practical, but 
> I think I read NAI3 very differently (in that it didn't 
> involve some sort of administrative process, but was just a 
> protocol concept). I believe (b) is different enough to be a 
> requirement in its own merit, though it also is probably not 
> uncontroversial.

NAI3 was intended to cover protocol means of passing the identity across
untrusted nodes. It was easier to extend it to out-of-band passing as well,
to avoid the need for a further requirement.

I am not proposing we address this requirement.

>  
> So even with a short-term view, I'm afraid I can't 
> immediately go along with these.

With the above clarifications, are you still opposed to NAI1 & NAI2 ?

...Mark

---------Mathematical definition of 'Trust Domain', for those so
inclined--->

Using the symbol 'e' for the usual set membership symbol ('is a member of')

Defn: A 'Trust Domain' is defined to be a set T of SIP elements (UAs,
Proxies etc.) and a set RT of unordered pairs of elements from T such that
for all x e T, {x,x} e RT. (RT is a subset of the set of ALL unordered pairs
from T)

Defn: A is 'T-trusted by' B iff { a, b } e RT.

Defn: An Identity I is said to be 'T-asserted' if it has been asserted by a
network element which is a member of T

Defn: An Identity I is said to be a 'Network Asserted Identity' if there
exist a Trust Domain T with more than one element such that I is T-asserted.

And now two interpretations:
i) a e T implies that a is known to operate strictly according to a set of
specifications Spec(T)
ii) { a, b } e R iff there exists a secure connection between a and b for
transmission of SIP messages (e.g. IPSEC, TLS, dedicated link etc.)

Real SIP elements are arranged into Trust Domains by human beings in some
unspecified (out of band) manner. This would require the definition of
Spec(T) for the trust domain T.

Note that every (untrusted) UA is a member of a trust domain all of it's
own.

Now the proposed requirements are to define a specification S such that if S
e Spec(T) then the following can be achieved (where T and U are Trust
Domains):
NAI1) The ability for an element A e T to securely pass a T-asserted
Identity to an element B e T, where A is T-trusted by B.
NAI2) The ability for an element A e T to securely pass a T-asserted
Identity to an element C, where NOT c e T.
NAI3) The ability for an element A e T to securely pass a T-asserted
Identity to an element B e T via another element C, where NOT C e T
NAI4a) The ability for an element A e T to pass a T-asserted Identity to an
element B, where NOT B e T
NAI4b) The ability for an element B e U to pass a Network Asserted Identity
to an element C e U, where  B is U-trusted by C.
NAI4c) The ability for an element B e U to pass a Network Asserted Identity
to an element C, where NOT C e U.

----------------------------------------------------------------------------
---
> So, no comments on the proposed requirements below. I take it 
> everyone agrees then ? 
> 
> ...Mark 
> 
---------Mathematical definition of 'Trust Domain', for those so
inclined--->

Using the symbol 'e' for the usual set membership symbol ('is a member of')

Defn: A 'Trust Domain' is defined to be a set T of SIP elements (UAs,
Proxies etc.) and a set RT of unordered pairs of elements from T such that
for all x e T, {x,x} e RT. (RT is a subset of the set of ALL unordered pairs
from T)

Defn: A is 'T-trusted by' B iff { a, b } e RT.

Defn: An Identity I is said to be 'T-asserted' if it has been asserted by a
network element which is a member of T

Defn: An Identity I is said to be a 'Network Asserted Identity' if there
exist a Trust Domain T with more than one element such that I is T-asserted.

And now two interpretations:
i) a e T implies that a is known to operate strictly according to a set of
specifications Spec(T)
ii) { a, b } e R iff there exists a secure connection between a and b for
transmission of SIP messages (e.g. IPSEC, TLS, dedicated link etc.)

Real SIP elements are arranged into Trust Domains by human beings in some
unspecified (out of band) manner. This would require the definition of
Spec(T) for the trust domain T.

Note that every (untrusted) UA is a member of a trust domain all of it's
own.

Now the proposed requirements are to define a specification S such that if S
e Spec(T) then the following can be achieved (where T and U are Trust
Domains):
NAI1) The ability for an element A e T to securely pass a T-asserted
Identity to an element B e T, where A is T-trusted by B.
NAI2) The ability for an element A e T to securely pass a T-asserted
Identity to an element C, where NOT c e T.
NAI3) The ability for an element A e T to securely pass a T-asserted
Identity to an element B e T via another element C, where NOT C e T
NAI4a) The ability for an element A e T to pass a T-asserted Identity to an
element B, where NOT B e T
NAI4b) The ability for an element B e U to pass a Network Asserted Identity
to an element C e U, where  B is U-trusted by C.
NAI4c) The ability for an element B e U to pass a Network Asserted Identity
to an element C, where NOT C e U.

----------------------------------------------------------------------------
---

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 19 Apr 2002 17:38:29 -0500

Well, in short, you have an admirable model that carves out a good
definition of the space of applicability of the short-term work. It has
actually helped me quite a bit to understand your position to stare at the
model (especially the distinction between NAI1, NAI3 and NAI4), so, thanks.
 
You have convineced me that the Iraqi problem is separable from NAI1, and
that we don't need to solve this problem in the proposed short-term work
provided that the short-term work embraces interpretations (i) and (ii) -
the current applicability statement in sip-privacy-04 is substantially
weaker than those. I think the fact that conformity to (i) and (ii) is not
reflected in the protocol must also become an important caveat to the
short-term work. I also hope that definition of an appropriate Spec(T) is
now a prerequisite for the short-term work? This could actually be
tractable...
 
I do however remain somewhat unconvinced on the separation of NAI1 and NAI2;
though I now understand the formal distinction you're drawing, any
behavioral motivations for the distinction remain unclear to me. If you take
as granted the caveat about privacy in NAI2, how would the behavior differ
for an entity sending an NAI to a trusted versus an untrusted destination?
If the answer is 'not at all', then you'll see why I'm saying you can
extract out the privacy requirement and conflate NAI1 and NAI2. In other
words, privacy creates the need to distinguish between these two. Or is
there some tacit requirement I'm missing that makes the behavior different
in this case? But otherwise I'm not opposed to the spirit of NAI1 and NAI2,
in any event. They seem like a reasonable scope for the short-term work.
 
A few other matters noted below.
 
Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: Mark Watson [mailto:[email-masked]]
Sent: Friday, April 19, 2002 10:06 AM
To: [email-masked]'; 'Peterson, Jon'
Subject: RE: [Sipping] RE: Network Asserted Identity

[snip]

If we don't have this requirement, then we don't need encryption. 
[Peterson, Jon] Well, the idea that a trust domain isn't a 'fully connected
network' is exactly what strikes the Internet-minded as a little odd. I
don't think the need for encryption is predicated on a network that isn't
fully connected. I think that encryption potentially enables the creator of
an NAI to determine who will be able to inspect it, rather than relying on
downstream entities to decide when they should or shouldn't share it with
others. An encrypted NAI that arrives at a UAS that cannot decrypt it meets
privacy requirements, I believe, regardless of call trace. I remain deeply
confused by the purpose of the encryption stuff in sip-privacy-04 (is it
anonymous call-back?). Since you're not considering NAI3 I presume this is
outside the context of the proposed short-term work.

[snip] 

I don't think the assumption you claim is made by the draft. 'Trustedness'
is indeed an 'opinion' that one node has about another, based on
configuration by human beings who know the properties of the devices (i.e.
that they are indeed compliant to the relevant specifications and so can be
trusted to act in a particular way).
[Peterson, Jon] Trustedness in the draft now is currently an opinion about
whom you receive an NAI from, which is oftentimes not the party that created
the NAI. Obviously, everyone should be entitled to their own degree of trust
with respect to the creator of the NAI, and this should have little or
nothing to do with who relays the NAI to you. This whole trusted network
concept forces you to trust everyone in the trust domain equally -
trustedness is an intrinsic, binary quality of elements and identities. I
think this is a fundamental limitation of the short-term work (it's built
into your model definitions), and ultimately your opinion of the value of
the short-term work is probably largely predicated on how damaging you
believe this limitation is.

---

From: "Mark Watson"<[email-masked]>
Date: Mon, 22 Apr 2002 13:37:38 +0100

Jon,
 
Distinction between NAI1 and NAI2 - I agree that in practice it is hard to
see why a single coding solution would not suffice for these two. So it is
debatable whether they need to be separated.
 
However, in terms of the Trust Domain model, they *are*different things -
passing an identity to another entity within the Trust Domain is a different
thing from passing it outside. The specification we develop as part of this
will specify procedures for passing the information to trusted and untusted
entities. Since we know that trusted entities DO follow these procedures
(part of the definition of Trust Domain) we COULD define something which
would meet NAI1 but not NA2 (because we would not define the procedures for
the NAI2 part).
 
I have stated the requirements independent of privacy - the requirement is
for the 'ability' to pass NAI about. I have not stated any requirements
about when this capability would be used, which would obviously depend on
where the information was going and its privacy status.
 
Further comments below.
 
...Mark

 <snip>

MW> The network is fully connected from a *connectivity* point of view, but
the network of 'Trusted' nodes with secure connections between them, which
is a kind of overlay, may not be connected. As soon as we leave the very
simple 'trusted nodes with secure connections' system, then we need
cryptography. 

MW> OK, I see your point. Yes, the Trust Domain concept relies on transitive
trust - within the scope of the NAI mechanism anything received from an
element that you know to be a member of the Trust Domain gets trusted, full
stop. i.e. there is no sense that information you receive has variable of
'trust status' depending (e.g.) on who *originally* generated it. It is part
of the procedures of a Trusted Element that it does not pass on to another
Trusted Element information which it doesn't trust (unless marked as such).

I now think that to meet NAI4 you would need some kind of indication of
*which* trust domain you received the identity from, rather than just the
'screen=yes' which only indicated that the information was from *some* Trust
Domain.

But now this is getting closer to your more general mechanism, which
indicates exactly which 'authentication service' generated the information
and works without the Trust Domain model.

...Mark