Subject: [abfab] Federation Terminology

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 12 Oct 2010 12:56:12 +0300

Hi guys, 

I was wondering whether someone of you has some good terminology for the
federation concept? 
In the draft writeup I prepared for the BOF
(draft-tschofenig-moonshot-ps) I ran into the problem of not having
useful terms. draft-hansen-privacy-terminology talks about identity
management but does not touch the topic of federations. 

I thought it would be useful to ask this group since the term
"Federated" appears many times in the charter text...

Ciao
Hannes

---

From: Sam Hartman <[email-masked]>
Date: Tue, 12 Oct 2010 08:55:34 -0400

Can you give some examples of the sorts of terminology problems you are
running into?  I suspect I've been solving some of them by being more
verbose and may not have noticed other issues.

--Sam

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 12 Oct 2010 17:57:21 +0300

Give me a good definition for "federation". 

I searched around and ran into the following definition (based on Y-2720):

"
federation: establishing a relationship between two or more entities or an association comprising 
any number of service providers and identity providers.
"

ISO/IEC CD 24760-1 does not have a term for federation but for identity federation instead. Here is it:

identity federation 
agreement between two or more domains  specifying how identity information  will be  exchanged and managed for cross-domain identification  purposes. Identity is set of attributes related to an entity. Entity is an item of interest, inside or outside an ICT system, such as a person, an organization, a device, a subsystem, or a group of such items that has recognizably distinct existence

I am not happy with both of these terms. 

Ciao
Hannes

On Oct 12, 2010, at 3:55 PM, Sam Hartman wrote:

> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab

---

From: Sam Hartman <[email-masked]>
Date: Tue, 12 Oct 2010 11:00:21 -0400

Both of those definitions seem consistent with what we've been doing.
So, I don't think we've hit a point yet where they fall apart.

--Sam

---

From: Eliot Lear <[email-masked]>
Date: Tue, 12 Oct 2010 17:06:11 +0200

Hi Hannes,

> I am not happy with both of these terms. 

And what makes you unhappy, and does it make you unhappy enough to want
to define yet a third set of terms?

Eliot

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 12 Oct 2010 18:35:11 +0300

Great to hear that you both are pretty easy when it comes to terminology. 

Why was I unhappy? 

I liked the Liberty Alliance definition more: "An association compromising any number of service providers and identity providers." maybe adding the AAA specific aspect that there are additional actors, such as brokers. The aspect that these entities belong to different administrative domains might also be worth mentioning.

I thought it would be useful to select one. 

Ciao
Hannes

---

From: Josh Howlett <[email-masked]>
Date: Tue, 12 Oct 2010 15:46:59 +0000

> I was wondering whether someone of you has some good terminology for
> the federation concept?

I think it's most helpful to think about a federation as describing the relationship between two or more actors. It's more of a social/business concept, than a technical one - if it's a technical one at all. I tend to think about a federation as a policy regime that allows the participating actors to derive some common expectations of each other.

Josh.

JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG

---

From: Sam Hartman <[email-masked]>
Date: Tue, 12 Oct 2010 11:49:05 -0400

I think I'll start to have an opinion about definitions when I get to a
point where one definition seems appropriate and another does not.

None of these seem to capture a concept that the Moonshot folks value: a
disconnect between the interaction between the subject and IDP and the
IDP and SP.  As we saw at the BOF, folks familiar with the US's federal
bridge CA point out that this disconnect is not necessary to achieve a
level of federation. However I'm quite certain that the Moonshot
proponents would not be happy with a bridge CA and moderately  they
would end up requiring the separation in interaction.

I'll note that none of these terms really capture that sort of
distinction.

So, until I understand exactly what we're trying to accomplish with
clear terminology, it's difficult for me to develop a strong opinion.  I
believe every definition you've proposed is within the general area of
where we're working.

--Sam

---

From: Josh Howlett <[email-masked]>
Date: Tue, 12 Oct 2010 16:04:14 +0000

> I thought it would be useful to select one.

I agree we should definitely define 'federated authentication' and probably also 'federated identity' (FWIW, SAML Glossary defines the latter, but not the former). I'm not sure if we really need to worry about the broader 'federation' concept, it might be a bit of a rat-hole.

Josh.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 12 Oct 2010 11:09:31 -0500

On Tue, Oct 12, 2010 at 06:35:11PM +0300, Hannes Tschofenig wrote:
> I liked the Liberty Alliance definition more: "An association
> compromising any number of service providers and identity providers."
> maybe adding the AAA specific aspect that there are additional actors,
> such as brokers. The aspect that these entities belong to different
> administrative domains might also be worth mentioning.

Sounds like you want better definitions rather than new terminology.

First, a nit: s/compromising/comprising/  :)

Second, I don't think mentioning specific technologies or types of
technologies in the definition of "federation" is terribly important
right now.  The essential question is: what do federations provide to
their members?

Now, "federation" can seem ambiguous, but that may be an advantage
because it may be too soon to draw strong distinctions between ongoing,
independent efforts in this area.  Consider, for example, ABFAB and
NFSv4.

Here in ABFAB it seems to mean "a collection of distinct administrative
domains which arrange for participating services to be able to
authenticate users, and obtain authorization-relevant information about
them, from participating domains".

Over in the NFSv4 WG the term "federated namespace" refers to a global
namespace constructed out of DNS SRV RRs, NFSv4 referrals, and
conventions for using LDAP to store information that NFSv4 servers need
to construct namespaces.  This surely seems unrelated to ABFAB but NFSv4
also has an aspect of identification, authentication and authorization
that is involved in creating a "federated namespace".

Some of us are proposing a method of constructing a federated namespace
for NFSv4 that covers the naming of users and groups of users, and which
ties authentication and authorization into the picture.

As you can see, there's some overlap between the NFSv4 concept of
federation and ABFAB's, yet the technologies involved are different.  To
be fair, I think NFSv4 could use ABFAB as one set or sub-set of
technologies in building NFSv4 federations -- after all, NFSv4 uses the
GSS-API.

But NFSv4 also needs name resolution services so that users can create,
view and edit access control lists (ACLs).  ABFAB provides no such
services.

Question: to what extent other ABFAB apps will need name services, and
should ABFAB provide them?

The slight ambiguity of the term 'federation' has proven useful to me:
it's helped me reach the point where I could ask the above question by
making me consider the differences and similarities between two
conceptions of 'federation'.

Nico
--

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Tue, 12 Oct 2010 09:09:45 -0700 (PDT)

> administrative domains might also be worth mentioning.

It has long been a problem that there are two common senses of the term 
"federation" in this area.  One is the pairwise sense you mentioned 
earlier:  a service in one administrative domain relies on identity 
services from another domain.  People say organizations "federate" when 
they make this pairwise arrangement.

The other is the multi-organizational sense you mention above, which is 
closer to the regular dictionary definition of federation.  There are lots 
of operational federations in this sense (see 
https://refeds.terena.org/index.php/Federations for a list in the 
research&education sector).

At the technical level that is the concern of abfab I think the pairwise 
definition is more relevant.  Sometimes I use the term 
"multi-organizational federation" to specifically indicate the second 
sense.

In any case I would suggest using the term "identity federation" for what 
we're talking about here, since "federation" per se has lots of other 
uses in IT (eg federated naming).

  - RL "Bob"

---

From: Josh Howlett <[email-masked]>
Date: Tue, 12 Oct 2010 16:23:02 +0000

> to construct namespaces.  This surely seems unrelated to ABFAB

Yes, they're unrelated at a technical level. At a business level, the act of delegating a set of responsibilities to the other party(ies) is similar.

> should ABFAB provide them?

I believe that some apps will need name services. I believe that ABFAB should provide these, where possible, by leveraging existing related mechanisms (e.g. SAML and/or RADIUS attributes).

Josh.

---

From: Eve Maler <[email-masked]>
Date: Tue, 12 Oct 2010 09:31:50 -0700

Here was my own entry into the federation terminology sweepstakes once upon a time... :-)

http://www.xmlgrrl.com/blog/2007/07/17/account-linking-and-the-f-word/

Also note that, while the F-word fits the abfab community comfortably, there are other communities that don't like the word but gravitate towards "trust" language more.  A bunch of terms relevant to federations are introduced here, for example:

http://openidentityexchange.org/sites/default/files/the-open-identity-trust-framework-model-2010-03.pdf

Even more terms are introduced in this old doc:

http://www.oasis-open.org/committees/download.php/6158/sstc-saml-trustmodels-2.0-draft-01.pdf

Hannes, if you feel inclined to write a federation equivalent of draft-hansen-privacy-terminology (!), I'm happy to try and help/review.

	Eve

> conceptions of 'federation'.

Eve Maler                                  http://www.xmlgrrl.com/blog
+1 425 345 6756                         http://www.twitter.com/xmlgrrl

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 12 Oct 2010 11:35:19 -0500

On Tue, Oct 12, 2010 at 04:23:02PM +0000, Josh Howlett wrote:
> Yes, they're unrelated at a technical level. At a business level, the
> act of delegating a set of responsibilities to the other party(ies) is
> similar.

Like I said, NFSv4 uses the GSS-API, so the two are not that unrelated.

ABFAB federations allow participating services to authenticate users
from participating domains and obtain useful authorization-relevant
information about such authenticated users.  Is that a fair
characterization?

NFSv4 federations allow at minimum for filesystem namespaces (possibly
built from many NFSv4 servers) of participating domains to be accessible
from others.  NFSv4's concept of federation is quite minimal in that
there need not be any sort of business or technical relationship between
participating domains other than use of the DNS.  But NFSv4 federations
can also cover name services for user and group names and determinations
of authenticated users' authorization contexts.  And this does involve
federated authentication (say, via Kerberos, via ABFAB, ...), and name
resolution services.

In its maximal form, NFSv4 federations don't seem unrelated to ABFAB,
not to me.

> I believe that some apps will need name services. I believe that ABFAB
> should provide these, where possible, by leveraging existing related
> mechanisms (e.g. SAML and/or RADIUS attributes).

Neither SAML nor RADIUS are remotely like name services...

Nico
--

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 12 Oct 2010 19:43:30 +0300

Hey Eve, 

I like the OIX writeup and I would use terminology from there but I wasn't able to spot something that explains a federation. There you seem to be talking about trust framework instead and that largely without defined terminology (which makes the document actually quite difficult to understand and to relate to work outside the OIX environment). I would also like to understand how far a trust framework (as described in the OIX document) relates to the federation concept.  

Ciao
Hannes

---

From: Eliot Lear <[email-masked]>
Date: Tue, 12 Oct 2010 19:24:00 +0200

Bob,

On 10/12/10 6:09 PM, RL 'Bob' Morgan wrote:
> At the technical level that is the concern of abfab I think the
> pairwise definition is more relevant.  Sometimes I use the term

Should this be an open question within the working group?  Josh has made
a convincing argument that, as Mike O'Dell said long ago, the only
problem you have to worry about is scale, and the ability to go greater
than pairwise would seem a necessary success ingredient.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Tue, 12 Oct 2010 19:27:51 +0200

Nico,

> Neither SAML nor RADIUS are remotely like name services...

When we say "name services" are we talking about agreements about
attribute names and their meanings, and the validity/trustworthiness of
the values?  SAML can certainly transport All Of That, and so could
Radius for that matter, but it's transport, right?

Eliot

---

From: Jim Fenton <[email-masked]>
Date: Tue, 12 Oct 2010 10:52:09 -0700

On 10/12/10 9:09 AM, RL 'Bob' Morgan wrote:
>> maybe adding the AAA specific aspect that there are additional 
>> actors, such as brokers. The aspect that these entities belong to 
>> different administrative domains might also be worth mentioning.
>
> It has long been a problem that there are two common senses of the 
> term "federation" in this area.  One is the pairwise sense you 
> mentioned earlier:  a service in one administrative domain relies on 
> identity services from another domain.  People say organizations 
> "federate" when they make this pairwise arrangement.
>
> The other is the multi-organizational sense you mention above, which 
> is closer to the regular dictionary definition of federation.  There 
> are lots of operational federations in this sense (see 

In the case of multi-organizational federation, I think it's also 
important to distinguish direct federations (where the parties all 
recognize each other) from indirect federations (where the parties 
possess a common accreditation, or perhaps belong to a trust 
framework).  There is obviously a severe scaling limitation with direct 
federations, but that is sufficient for many enterprise use cases.

In the indirect case, the parties need to recognize some sort of 
certificate or verify the relationship with the accreditor or trust 
framework, and detect and handle revocation of the relationship.  This 
has direct impact on the protocols.
>
> In any case I would suggest using the term "identity federation" for 
> what we're talking about here, since "federation" per se has lots of 
> other uses in IT (eg federated naming).

+1.  I hope that "federation" does not become as overused as "virtual" 
or "cloud"!

-Jim

---

From: Josh Howlett <[email-masked]>
Date: Tue, 12 Oct 2010 18:23:07 +0000

Josh.

---

From: "Scott Cantor" <[email-masked]>
Date: Tue, 12 Oct 2010 14:31:37 -0400

> has direct impact on the protocols.

It doesn't have to, it's simply there. The verification of that sort of
thing can be kept outside of a protocol's "runtime" decision making process
so that people can use different trust models with common protocol
implementations.

Failing to maintain that separation ends up imposing a particular trust
model on the credentials used by the parties at runtime, and that usually
ends up dictating the credentials themselves, which is where the whole thing
blows up.

-- Scott

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 12 Oct 2010 13:47:17 -0500

> Radius for that matter, but it's transport, right?

Say I want to add to some ACL an entry granting "[email-masked]" access
to some file.  The server is likely going to need to resolve that into
whatever the primary key[*] might be for [email-masked] so it can store
that on disk.

That's a name resolution issue, and there is no place for RADIUS in
there.  SAML is not a protocol, so SAML can't really fit this either,
though a name resolution protocol could very well use SAML.

The obvious protocol for name resolution here is LDAP.  That's what
we'll be using in NFSv4.  See:

    draft-adamson-nfsv4-multi-domain-access-03.txt

Nico

[*] Or the server could just store [email-masked] on disk, and
    hopefully foo.example will never re-use the name "joe" and,
    preferably, will ensure that joe remains part of joe's authorization
    context should joe ever get renamed.

    We can realistically expect administrators never to re-use what I
    meant by primary keys: SIDs, UIDs, GIDs, employee IDs, etcetera,
    because that is already a common practice.  But expecting them to
    never re-use names is less realistic, thus an NFSv4 server is likely
    to prefer storing primary keys over names.  In this example the
    server might prefer to store {joe's ID at foo.example, some ID for
    foo.example} on disk.

---

From: Josh Howlett <[email-masked]>
Date: Tue, 12 Oct 2010 18:51:00 +0000

> information about such authenticated users.  Is that a fair

It's one of the best descriptions to date, I think!

(I would personally drop the word "federation" because I don't think it adds anything, and risks introducing unrelated concepts associated with this over-loaded term. But that's just me - if it works for others then that's great)

> In its maximal form, NFSv4 federations don't seem unrelated to ABFAB,

Definitely in the sense that ABFAB can be a service to NFS.

> Neither SAML nor RADIUS are remotely like name services...

Sure, it makes no sense to reinvent name services on these. I meant that these could supply useful data that might inform name services (e.g., identifiers).

Josh.

---

From: "Scott Cantor" <[email-masked]>
Date: Tue, 12 Oct 2010 15:00:33 -0400

> though a name resolution protocol could very well use SAML.

SAML is actually a protocol, and there is a specific protocol in the
original "family" of protocol exchanges for NameIDMapping that more or less
fits the use case. Just FYI.

-- Scott

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 12 Oct 2010 14:01:07 -0500

> It's one of the best descriptions to date, I think!

Er, glad to help then!

> (I would personally drop the word "federation" because I don't think
> it adds anything, and risks introducing unrelated concepts associated
> with this over-loaded term. But that's just me - if it works for
> others then that's great)

I think right now it's a useful term.  Eventually we're going to need to
differentiate different kinds of federations enough that we may need to
ditch this term and invent a new one, or else qualify it.

> Definitely in the sense that ABFAB can be a service to NFS.

Right.  But see draft-adamson-nfsv4-multi-domain-access, which describes
how to do name resolution and, to a lesser extent, ID mapping in a
federated namespace.  That piece could prove useful to ABFAB.

> Sure, it makes no sense to reinvent name services on these. I meant
> that these could supply useful data that might inform name services
> (e.g., identifiers).

Agreed.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 12 Oct 2010 14:01:52 -0500

> fits the use case. Just FYI.

Oh.  Could you send me some references?

Nico
--

---

From: "Scott Cantor" <[email-masked]>
Date: Tue, 12 Oct 2010 15:12:02 -0400

> Oh.  Could you send me some references?

The abstract protocol layer and the protocols that are actually defined in
the original standard are all in the Core spec:

http://saml.xml.org/saml-specifications

NameID Mapping is sec 3.8. It's just a translation message to turn one name
form at an IdP into another. The primary use case was getting encrypted
references to a principal at another IdP to do identity cross-walks, but it
can translate names at a single IdP.

-- Scott

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 12 Oct 2010 14:42:52 -0500

> fits the use case. Just FYI.

Incidentally, I tend to think of SAML profiles as protocols, but SAML
alone as not.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 12 Oct 2010 14:53:13 -0500

> can translate names at a single IdP.

Thanks.  This is quite useful.  I'll have to bring this up in discussion
of draft-adamson-... and draft-sorce-...

One problem is that urn:oasis:names:tc:SAML:2.0:nameid-format:entity has
not specified format, so who knows whether what you get back is a SID or
something else.

There's also urn:oasis:names:tc:SAML:2.0:nameid-format:persistent, whose
semantic seems to be that it is a random string, but a persistent one.

The other nameid-formats aren't all that useful here.

Having nameid-formats specific to "SID", "POSIX UID" and "POSIX GID"
would be quite handy.  How hard would it be to add such nameid-formats?

(My apologies to the list if this starts getting OT.)

Nico
--

---

From: "Scott Cantor" <[email-masked]>
Date: Tue, 12 Oct 2010 16:06:22 -0400

> not specified format, so who knows whether what you get back is a SID or

No, that format is reserved for SAML entityIDs, typically for identifying
SAML services and applications, not users.
 
> semantic seems to be that it is a random string, but a persistent one.

That also has a well-defined semantic, and is something akin to what DCE did
with the underlying UUID underneath the principals and groups.
 
> would be quite handy.  How hard would it be to add such nameid-formats?

Formats are just URIs to signal intent, anybody can invent them.

> (My apologies to the list if this starts getting OT.)

Likewise.

-- Scott

---

From: Josh Howlett <[email-masked]>
Date: Tue, 12 Oct 2010 20:09:07 +0000

> ends up dictating the credentials themselves, which is where the whole thing

One of the motivations of the Key Negotiation Protocol (draft-howlett-radsec-knp), which is a proposed application of AFAB, is to permit the separation of credential technologies; such that two actors can wield entirely unrelated types of credential, and yet still arrive at a trust decision at runtime.

This is intended to complement the credential/protocol separation strategy that Scott describes (and which I think should be axiomatic), by introducing a further separation between the credential technologies themselves.

Josh.

---

From: Jim Fenton <[email-masked]>
Date: Tue, 12 Oct 2010 13:45:37 -0700

> ends up dictating the credentials themselves, which is where the whole thing

I'm assuming the separation between the subject-IDP interaction and the 
IDP-SP interaction that Sam wrote about a little earlier in this 
thread.  When you have that separation, you avoid dictating the 
credentials themselves.  But you still have the relationships between 
different SPs that needs to be federated, and there needs to be some 
basis for deciding who's a member of "the club", and whether anyone has 
been kicked out.

-Jim

---

From: "Scott Cantor" <[email-masked]>
Date: Tue, 12 Oct 2010 16:49:01 -0400

> credentials themselves.

I was talking about the system credentials, not the user credentials.

> But you still have the relationships between

Yes, but if you bind that into the federated protocol itself instead of
decoupling it through something like SAML metadata, you have the problem
that in order to interfederate and scale, you need to immediately federate
the trust mechanism itself. Keeping things layered means you can scale more
effectively without running into the problem of needing to juggle ten
different server credentials to deal with ten different federations.

-- Scott

---

From: Luke Howard <[email-masked]>
Date: Wed, 13 Oct 2010 11:19:18 +1100

> though a name resolution protocol could very well use SAML.

Right, see Scott's message.

>    context should joe ever get renamed.

This is a good point which I had conveniently forgotten.

-- Luke

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 12 Oct 2010 19:38:29 -0500

> Right, see Scott's message.

Done :)

> This is a good point which I had conveniently forgotten.

There's several problems with this: a) you can't validate (catch typos,
canonicalize, ...), b) you can't re-use names (which not a lot of
administrative domains are prepared to do), c) it's harder to deal with
this in filesystems (e.g., ZFS interns domain SIDs, now it'd have to
intern names, but at least it has a 64-bit namespace for that, whereas
other filesystems have much smaller namespaces).

(b) is the worst problem in the short-term, while (a) is the worst
problem in the long-term.

Those are not fatal problems.  I'd rather not have to deal with those
problems, but in a pinch I'd live with them.

Nico
--

---

From: Eve Maler <[email-masked]>
Date: Fri, 15 Oct 2010 10:38:52 -0700

Sorry for the delayed response!

In earlier drafts of the paper we used to talk about "trust communities", but I guess we ended up taking that language out.  In any case, I was thinking that a trust framework and its members collectively make up what could be called a federation.  The technical, legal, and operational requirements for exchanges of identity information are (a) decided on by policymakers, (b) instantiated in a framework that is run by a trust framework provider (== federation operator), and (c) has members whose compliance to the requirements is measured in some fashion.

(There's no particular additional benefit to using the non-F-word language, but it's good to know how to translate across to that language for those who prefer it.)

	Eve

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 15 Oct 2010 13:30:35 -0500

On Fri, Oct 15, 2010 at 10:38:52AM -0700, Eve Maler wrote:
> In earlier drafts of the paper we used to talk about "trust
> communities", but I guess we ended up taking that language out.  In
> any case, I was thinking that a trust framework and its members
> collectively make up what could be called a federation.  The
> technical, legal, and operational requirements for exchanges of
> identity information are (a) decided on by policymakers, (b)
> instantiated in a framework that is run by a trust framework provider
> (== federation operator), and (c) has members whose compliance to the
> requirements is measured in some fashion.

The problem with "trust" is that it's become a bad word -- there's too
much it could denote, and anyways it's too scary.

Federation is much nicer word.  Its English language meaning denotes
independence in decision making (such as about degrees of trust).

Linguistic considerations do matter.  After all, we're selling this sort
of thing to people who won't know and understand the term-of-art
meanings of these terms, so the closer we can their semantics to their
natural language counterparts, the better.

There is some risk of overusing the F word -- we've overused "trust",
after all, and now it's not nearly as useful as it once seemed.

> (There's no particular additional benefit to using the non-F-word
> language, but it's good to know how to translate across to that
> language for those who prefer it.)

Yes.

Nico
--