ABFAB                                                         J. Howlett
Internet-Draft                                                  R. Smith
Intended status: Informational                                     Janet
Expires: September 12, 2013                                 M. Wasserman
                                                       Painless Security
                                                          March 11, 2013


                Trust Requirements in a Federated World
                 draft-howlett-abfab-trust-router-ps-03

Abstract

   TODO: This document outlines the requirements for trust in a
   federated environment, and enumerates the requirements for a trust
   infrastructure.  It also examines existing trust infrastructures
   given these requirements and concludes that none fulfil all of the
   requirements, and suggests that maybe a new one is required that
   does.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 12, 2013.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must



Howlett, et al.        Expires September 12, 2013               [Page 1]


Internet-Draft                    Trust                       March 2013


   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Trust  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     3.1.  What is Trust? . . . . . . . . . . . . . . . . . . . . . .  4
     3.2.  Communities of Trust . . . . . . . . . . . . . . . . . . .  5
     3.3.  Authentication Policy Communities vs Communities of
           Interest . . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.4.  Trust in a federated environment . . . . . . . . . . . . .  8
   4.  Trust requirements in a federated world  . . . . . . . . . . .  9
     4.1.  General Requirements . . . . . . . . . . . . . . . . . . .  9
       4.1.1.  Identifying Partners . . . . . . . . . . . . . . . . .  9
       4.1.2.  Connecting to Partners . . . . . . . . . . . . . . . .  9
       4.1.3.  Clearly Delineate Registration from Usage  . . . . . .  9
     4.2.  Specific Requirements  . . . . . . . . . . . . . . . . . . 10
       4.2.1.  Many IdPs, Many RPs  . . . . . . . . . . . . . . . . . 10
       4.2.2.  Frequent changes in Community Membership . . . . . . . 10
       4.2.3.  Costs incurred by community that benefits  . . . . . . 10
       4.2.4.  Minimal Costs/Effort for forming new communities
               of Interest  . . . . . . . . . . . . . . . . . . . . . 11
       4.2.5.  Flexible Communities . . . . . . . . . . . . . . . . . 11
       4.2.6.  Flexible Trust Links . . . . . . . . . . . . . . . . . 11
       4.2.7.  Multi-Role participation . . . . . . . . . . . . . . . 12
       4.2.8.  Multi-Purpose communities  . . . . . . . . . . . . . . 12
   5.  Analysis of existing Trust infrastructures . . . . . . . . . . 12
     5.1.  PKIX . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     5.2.  PGP style web of trust . . . . . . . . . . . . . . . . . . 12
     5.3.  SAML Metadata  . . . . . . . . . . . . . . . . . . . . . . 12
     5.4.  FreeRADIUS shared secrets  . . . . . . . . . . . . . . . . 13
     5.5.  Other Things?  . . . . . . . . . . . . . . . . . . . . . . 13
   6.  The Future of Trust  . . . . . . . . . . . . . . . . . . . . . 13
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   9.  Privacy Considerations . . . . . . . . . . . . . . . . . . . . 13
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 14
     11.2. Informative References . . . . . . . . . . . . . . . . . . 14








Howlett, et al.        Expires September 12, 2013               [Page 2]


Internet-Draft                    Trust                       March 2013


1.  Introduction

   Trust is a concept whose exact definition differs depending on the
   exact scenario in which it is being applied, however, there is a
   large degree of commonality about the meaning across all contexts -
   the idea of "trust" usually centres around two entities (be they
   people, organisations, or whatever) establishing confidence and faith
   in the reliability, truth, or abilities of each other.

   In the world of federated technologies, trust typically means exactly
   that: two federated entities being able to establish confidence in
   each other.  What this means more specifically is that two entities
   are able to verify that each other is who they think they are (i.e.,
   that it is not another entity pretending to be someone else), that
   they represent the organisation they say they do (i.e. an entity
   isn't misrepresenting themselves), and that transactions between the
   two can be secure, unaltered, and verifiable.

   This document examines the requirements of a trust infrastructure in
   this context of the federated world.  It then looks at existing trust
   infrastructures, examining their pros and cons in relation to these
   defined requirements.  It then draws some conclusions about work
   needed to bridge some missing gaps.

2.  Terminology

   This document uses existing terminology that the reader may not be
   familiar with - and also introduces some new terminology - so a small
   set of definitions is now included.

   o  Authentication Policy Community (APC): A set of entities that
      share a common trust infrastructure and a common set of
      identification requirements for the entities to be admitted to the
      community.

   o  Community of Interest (CoI): A set of federation-capable entities
      who want to interact with each other for a common purpose and with
      a specific set of requirements.

   o  Entity: A general term for IdPs and RPs.

   o  Federation: An agreement between various entities that allows for
      delegation of trust based a common set of semantics between an RP
      and an IdP.

   o  Identity Provider (IdP): An entity that asserts identity
      information about its principals to RPs.




Howlett, et al.        Expires September 12, 2013               [Page 3]


Internet-Draft                    Trust                       March 2013


   o  Principal (or Client): An individual (i.e. a real world person) or
      a computer that is registered with an IdP and is attempting to get
      service from an RP.

   o  Relying Party (RP): (a.k.a.  Service Provider (SP)) The federated
      entity representing an organisation that consumes identity
      information about a principal asserted by an IdP in order to
      provide a service to that principal.

   o  Trust Arbitrator: A central point of trust infrastructure that
      gathers and passes on crowd-sourced trust recommendations about
      members of its APC.  The entities within the APC provide trust
      recommendations to the arbitrator: the arbitrator does not make
      trust recommendations on its won.  The entities in the APC trust
      that the Trust Arbitrator will ensure that recommendations from
      the APC membership are correctly reflected in the trust rating
      presented.

   o  Trust Advisor: A central point of trust infrastructure who
      entities rely on it to (make trust recommendations about other
      entities and?) trust decisions about who is admitted to a CoR
      based on a set of advertised criteria.

   o  Web of Trust: A mechanism for extending trust between two
      different trust infrastructures where an agreement exists that
      each of the trust infrastructures can use the judgment of the
      other infrastructure to make its own trust decisions.  A Web of
      Trust can be transitively extended across multiple trust
      infrastructure.  In other words, you and all your friends become
      my friends.

3.  Trust

3.1.  What is Trust?

   Trust is a word and a concept that can mean many things depending on
   the context in which it is being discussed, and can encompass a wide
   range of requirements.  For example:

   o  In personal relationships, trust between two friends is usually a
      mutually established relationship where each can rely on the other
      for confidentiality and their help in times of need.

   o  In airline travel, trust between a consumer and an airline
      provider is largely a one way relationship where the trust of the
      airline by the consumer means the consumer expects the airline to
      keep their aircraft well maintained, to get them to their
      destination alive and (roughly) on time, and to (try) not to lose



Howlett, et al.        Expires September 12, 2013               [Page 4]


Internet-Draft                    Trust                       March 2013


      their luggage.

   o  In e-commerce, trust between a consumer and a vendor is also
      largely a one way relationship where the trust of a vendor by a
      consumer means that the consumer considers the vendor to be likely
      to provide good service, a reasonable price, and to fulfil their
      order after it has been paid for.

   Many such examples of trust exist in all walks of life and across
   many contexts.  Across most - if not all - of these, some
   commonalities appear in the meaning of trust.  Trust usually centres
   around two entities being able to prove to each other who they are,
   and then use that as a basis to transact in some form in a manner
   that is confidential and secure.  Indeed, the OED defines trust as
   "Confidence in or reliance on some quality or attribute of a person
   or thing, or the truth of a statement".

3.2.  Communities of Trust

   Trust, as defined above, is not something that just appears from
   nowhere - it must be established somehow.  The simplest way is, of
   course, for two entities to build it bilaterally through a process of
   slowly increasing the level of trust in each other through a series
   of transactions over time.  This process can be expedited, however,
   through one of three commonly employed methods:

   1.  Trust can be established transitively through commonly trusted
       3rd parties who have previously built up a level of trust with
       each other (i.e. a web of trust, such as is seen in the PGP web
       of trust)

   2.  Trust can be bootstrapped indirectly by a Trust Arbitrator - an
       entity that is trusted by all who make use of it to appropriately
       manage community provided reviews of trust (e.g., recommender
       systems such as eBay member ratings)

   3.  Trust can be bootstrapped directly by a Trust Advisor - an entity
       that is trusted by all who make use of it to appropriately manage
       directly established trust relationships between it and its
       community members (e.g., X509 Certificate Authorities).

   In practice, each of these mechanisms can be, and are, used in
   different contexts.  They are typically deployed on a per-community
   basis, such as the eBay community, a research and education SAML
   federation, PGP users, web site deployers, etc. - because in a world
   of billions of people and many millions of organisations, each of
   whom is a member of many communities, finding a single entity, or a
   small number of entities, that are commonly trusted by all to be a



Howlett, et al.        Expires September 12, 2013               [Page 5]


Internet-Draft                    Trust                       March 2013


   Trust Arbitrator or a Trust Advisor is simply impossible.  So, as a
   way of tackling this scaling issue, "Communities of Trust" have
   organically appeared in all three guises of expedited trust
   establishment: sometimes in a decentralised way (e.g.  PGP key
   management through a web of trust), sometimes arbitrated by a Trust
   Arbitrator (e.g.  Trust management between sellers and buyers on
   eBay), and sometimes by a Trust Advisor (e.g.  X509 CAs, Twitter
   "verified accounts", SAML federation metadata managed by the
   federation operators, etc).

   Within the world of computing, Trust Advisors are a typical way of
   establishing trust, as it is essentially a method for people or
   organisations to outsource the problem of trust establishment.
   However, to achieve this, someone or something needs to set up and
   manage the Trust Advisor, and users of it typically need to pay for
   the service.  Consequently, this method of solving the trust
   establishment problem is largely used in business to business and
   business to consumer communities.  However, for those communities
   where no financial transactions are involved, this method of trust
   establishment is less appropriate as the community members do not
   always want to - or are unable to - pay for the service.

   Trust Arbitrators are less commonly seen, and are usually found where
   a Trust Arbitrator stands to make financial gain through the use of
   its services - either directly (e.g. members pay for its trust
   recommendations) or indirectly (e.g. a chargeable service having more
   members because of the increased trust these members can have in each
   other).  Again, this method may not be appropriate for those
   communities where financial transactions are not involved.

   The Web of Trust method of establishing trust is least seen of the
   three methods, since while it is decentralised and appropriate for
   any type of community, including those where no financial
   transactions are taking place - transitive trust can be built up in a
   way without paying for it - it is the hardest and most time consuming
   way of establishing trust.

3.3.  Authentication Policy Communities vs Communities of Interest

   In those scenarios where Trust Arbitrators or Trust Advisors are the
   methods of bootstrapping trust, two separate communities actually
   exist.  However, the two are often conflated as they are typically
   equal, by accident of design.  These two communities are:

   o  The Authentication Policy Communities: the set of entities who are
      known to a trust infrastructure and for which the trust
      infrastructure has a notion of trustworthiness.




Howlett, et al.        Expires September 12, 2013               [Page 6]


Internet-Draft                    Trust                       March 2013


   o  The Community of Interest: the set of entities who want to
      interact with each for some particular purpose (e.g. to do B2C to
      B2B transactions, to collaborate as part of a cross-organisational
      project, to communicate securely, etc).

   These two types of communities are often conflated because of the
   lack of Trust Arbitrators or Trust Advisors that span multiple
   communities of interest.  This results in each community of interest
   using a single (or small amount of) Trust Arbitrators or Trust
   Advisors, thus the Authentication Policy Communities and Community of
   Interest are one and the same.

   In the real world, however, there are many cases where communities of
   interest want to span multiple Authentication Policy Communities.
   For example, SAML entities in the education sector who are part of
   different Authentication Policy Communities (i.e.  SAML Federations)
   that are often geographically split (each country typically runs its
   own SAML federation) often desire to communicate; [TODO other
   examples].

   When entities from different communities of interest want to transact
   in this way, trust has to be established across communities.  This
   can achieved in one of three ways:

   1.  Entities can join multiple communities, if the technology allows
       this.

   2.  A Trust Bridge can be set up between Trust Arbitrators/Advisors
       to allow entities from different Authentication Policy
       Communities to communicate.

   3.  A Trust Arbitrators/Advisors can attempt to become the arbiter of
       trust for multiple communities.

   The first of these options is a rather inelegant way of solving the
   problem, and will likely involve significant organisational effort
   per community the entity joins, and is therefore not a particularly
   scalable solution, and is therefore only a workable workaround in
   limited circumstances.

   The second option scales much better but requires significant effort
   by the Trust Arbitrators/Advisors in ensuring that their rules of
   registration are compatible.

   The third option has significant drawbacks, however - either the
   Trust Arbitrators/Advisors has to relax its rules so much to be
   inclusive for a range of communities of interest that it becomes very
   limited in the assurances it can offer, or it has to impose a set of



Howlett, et al.        Expires September 12, 2013               [Page 7]


Internet-Draft                    Trust                       March 2013


   standards that many entities will not be willing to opt into due to
   the high costs it imposes on them to meet these standards.

3.4.  Trust in a federated environment

   Given the general view of trust presented above, what does trust look
   like more specifically in the federated world?

   In a federated world, there are a few types of entities and trust
   relationships, to whom trust each means slightly different things.
   There is:

   o  Principal to IdP, IdP to principal.  Trust here is mostly
      organisational around an existing relationship between principal
      and their IdP.  The principal trusts the IdP to control its data
      properly and to assert correct information about them.  The IdP
      trusts the principal to keep their credentials confidential so
      that the IdP can authenticate the principal when required.

   o  Principal to RPs, RPs to principal.  Trust here mostly flows
      through guarantees between the principals and its IdP, and that
      IdP and the RP, that allow the user to gain access to services
      offered by the RP.

   o  IdP to RP.  Trust here centres on the IdP and RP being able to
      verify each other's identities, and often associate that
      identification with an existing business relationship between the
      organizations.

   So in a federated world, there are actually two types of trust in
   play.  Firstly, there is technical trust (i.e., is the server I'm
   talking to really the one I think it is, and are all communications
   secured?); and secondly there is organisational or behavioural trust
   (i.e., the trust that allows two entities to know for sure that that
   the other entity represents a particular organisation that they have
   a business relationship with, what guarantees are in place with each
   other about their relationship, etc).

   The second of these is a real world problem to be addressed and not a
   technological issue and thus needs to be solved out of band.  It
   might, of course, have technical components to it (e.g. schema
   definitions so the two understand the semantics of the data
   transferred back and forth), but those would be part of the out of
   band negotiation.

   The first, however, is at the core of federation.  The next section
   looks in more detail at what federation needs from a trust framework
   to properly establish technical trust.



Howlett, et al.        Expires September 12, 2013               [Page 8]


Internet-Draft                    Trust                       March 2013


4.  Trust requirements in a federated world

   The requirements of technical trust in a federated world largely
   centre on entities being able to verify each others identity and
   establish secure communications channels to allow for signing,
   encryption, etc.  To achieve this, various properties of the trust
   infrastructure are required.  Some of these requirements are
   absolutely critical, while some are optional requirements to help
   with scale.  These are detailed next.

4.1.  General Requirements

   First of all, we will look at the main general requirements.

4.1.1.  Identifying Partners

   In most cases, it is necessary for organisations to have confidence
   that the configuration that they have for their partners actually
   corresponds to their partners and is not, for example, an attacker
   claiming to be their partner.  This is largely an issue of vetting
   the claimed identity of organisations when they join a community.

   An additional requirement here is that organisations need to minimise
   the cost of validating their partners' identities, and of proving
   their own identity to their partners.

4.1.2.  Connecting to Partners

   This is probably the most obvious requirement.  Organisations must be
   able to establish trust with each other through configuration, i.e.,
   servers representing a particular organisation must be configured to
   be able to connect to servers representing partners of that
   organisation in a secure verifiable manner.

   To be able to connect, the configuration must include such things as
   specifying the protocols to be used and the cryptographic operations
   to be used.

   Additionally, to be able to effectively connect to partners,
   organisations must have effective tools for managing policies that
   control the flow of information between the two partners.

4.1.3.  Clearly Delineate Registration from Usage

   As detailed earlier, the conflation of Authentication Policy
   Communities vs Comunities of Interest hinders progress of large scale
   adoption of federation and transitive trust establishment.
   Conceptually splitting those two out gives many advantages, not the



Howlett, et al.        Expires September 12, 2013               [Page 9]


Internet-Draft                    Trust                       March 2013


   least of which is the possibility of being able to better support
   communities of interest that span multiple Authentication Policy
   Communities.  Authentication Policy Communities will provide the
   technical trust, while Communities of Interest overlain upon one or
   more Authentication Policy Communities can provide the behavioural
   trust.

4.2.  Specific Requirements

   Alongside the general requirements presented above, there are some
   more specific requirements.  These are discussed next.

4.2.1.  Many IdPs, Many RPs

   Entities must be able to establish trust with an arbitrary number of
   partners - scale should not be an issue.

4.2.2.  Frequent changes in Community Membership

   It must be possible to support changes in membership (adding new
   partners, removing former partners, or changing the configuration of
   partners) with minimal operational effort, and without requiring
   manual configuration changes that could result in new partners having
   delayed or incomplete access to services, or former partners
   retaining some access to services beyond the end of their membership.

   Additionally, organisations want to minimise the cost of managing
   these frequent changes - there should be no requirement for
   credential exchange between a large number of parties, no manual
   configuration changes on a large number of systems, etc.

   This is a requirement for both Authentication Policy Communities and
   Communities of Interest, though the scale of changes is likely to be
   different in the two.

4.2.3.  Costs incurred by community that benefits

   Typically in federation, the operational cost related to adding and
   removing partners is born by the RPs, who need to maintain bilateral
   credentials for each IdP whose users can access the services provided
   by the RP.  This is fine in a case where a single RP provides
   services to a group of IdPs that pay for membership in the community,
   or pay for access to specific services.

   However, in a less-centralised partnership the costs of exchanging
   credentials with each IdP could serve as a disincentive for
   organisations to provide services to the community and/or result in
   cases where an RP is unwilling or unable to incur the costs of



Howlett, et al.        Expires September 12, 2013              [Page 10]


Internet-Draft                    Trust                       March 2013


   providing access to new partners.  Therefore, if a trust framework
   supported a mechanism where the operational costs are distributed to
   the organisations that are receiving benefit from incurring the
   costs, it would help drive adoption and usage.

4.2.4.  Minimal Costs/Effort for forming new communities of Interest

   To expand the use of federated services, it should be possible for a
   group of potential partners to form a new Community of Interest with
   minimal infrastructure and the lowest possible operational expense.

   In order to minimise start-up costs, it should be possible to
   leverage existing shared credentials and use those credentials for a
   new Community of Interest.

   Practically, this resolves to two problems:

   o  It must be possible to create a new Community of Interest that
      uses credentials from one or more existing Authentication Policy
      Communities.

   o  It must be possible for a partner to join multiple Communities of
      Interest using a shared Authentication Policy Community, and for
      different entities (such as users or servers) within a partner to
      participate in different Communities of Interest.  Practically,
      this means that information about the Community of Interest in use
      needs to be transmitted to an IdP, so it can be used as part the
      authentication process.

4.2.5.  Flexible Communities

   It should be possible for Communities of Interest to grow to
   encompass more partners, partners in different regions of the world,
   or partners who have different Authentication Policy Communities
   available to them.

   It must, therefore, be possible for a single Community of Interest to
   be serviced by multiple Authentication Policy Communities.  While it
   might be necessary for any given RP/IdP pair to share at least one
   Authentication Policy Community, it should not be necessary for all
   of the partners within a given Community of Interest to share a
   single Authentication Policy Community.

4.2.6.  Flexible Trust Links

   Related to the above, it should be possible for Communities of
   Interest that span multiple Authentication Policy Communities to be
   able to support that transitive establishment of trust over these no



Howlett, et al.        Expires September 12, 2013              [Page 11]


Internet-Draft                    Trust                       March 2013


   matter what technology is used for trust establishment in each
   Authentication Policy Communities.  This will help increase the
   flexibility of communities.

4.2.7.  Multi-Role participation

   It must be possible for a single partner to participate as both an RP
   and an IdP within a single community (either a Community of Interest
   or a Authentication Policy Communities).

4.2.8.  Multi-Purpose communities

   It must be possible for a particular Community of Interest to be
   equivalent in membership and configuration as an Authentication
   Policy Community.  A use case for this requirement would be an
   Authentication Policy Community that provides services to its own
   customers, perhaps for maintenance of their own Authentication Policy
   Community membership.

5.  Analysis of existing Trust infrastructures

   TODO: Intro to this section.  N.B. Much more detail needed, should be
   a decent amount of analysis.  Not a huge amount though - severa paras
   per tech, perhaps.

5.1.  PKIX

   TODO: A trust advisor (or small set of trust advisors) in the form of
   heirarchically signed X509 certs.  Only Authentication Policy
   Communities, not CoI.  Costs incurred by the service, not the user.
   Works well but only when governance and management is done properly.
   Which it isn't, generally.  Can devolve trust establishment a bit
   with intermediate certs.

   TODO: Not particularly suitable to federation in the real world as
   existing X509 heirarchies are usually not run well enough, and
   running one well enough is a significant cost.

5.2.  PGP style web of trust

   TODO: Web of trust style trust establishment, obviously.  Works well
   but not massively deployed because of the technology understanding
   required of users to sign each others keys and whatnot.

5.3.  SAML Metadata

   TODO: Can use PKIX, or directly established public/private keys
   through metadata, to establish trust.  In the former case, all of



Howlett, et al.        Expires September 12, 2013              [Page 12]


Internet-Draft                    Trust                       March 2013


   PKIX drawbacks.  In the latter, needs a trust advisor controlling the
   SAML metadata.  Usually conflates APC with CoI (though entity
   categories allow for CoI in a very limited sense).  Doesn't scale
   well because of it!  Interfederation as a point solution to scaling
   having to be designed.

5.4.  FreeRADIUS shared secrets

   TODO:

5.5.  Other Things?

   TODO:

6.  The Future of Trust

   TODO: Trust is something that needs engineering - trust frameworks
   and systems are needed that fulfil all of the requirements stated if
   we want a way of establishing trust between two artibrary federation
   entities that cross arbitrarily large and diverse communities, and in
   a way that empowers the actual users of the systems to make best use
   of it all.  No particular solution fulfils all of the requirements
   above that are necessary for wide adoption of federation in a way
   that is easy and cost effective for the communities using it.  Any
   new solution should consider all of these needs.

7.  Acknowledgements

   TODO: The document authors would like to thanks Jim Schaad and Klaas
   Wierenga for providing review.

8.  Security Considerations

   TODO.

9.  Privacy Considerations

   TODO.

10.  IANA Considerations

   This document does not require actions by IANA.

11.  References







Howlett, et al.        Expires September 12, 2013              [Page 13]


Internet-Draft                    Trust                       March 2013


11.1.  Normative References

   [OASIS.saml-profiles-2.0-os]  Hughes, J., Cantor, S., Hodges, J.,
                                 Hirsch, F., Mishra, P., Philpott, R.,
                                 and E. Maler, "Profiles for the OASIS
                                 Security Assertion Markup Language
                                 (SAML) V2.0", OASIS
                                 Standard OASIS.saml-profiles-2.0-os,
                                 March 2005.

11.2.  Informative References

Authors' Addresses

   Josh Howlett
   Janet
   Lumen House
   Library Avenue
   Harwell Oxford
   Didcot  OX11 0SG
   United Kingdom

   EMail: josh.howlett@ja.net


   Dr. Rhys Smith
   Janet
   Lumen House
   Library Avenue
   Harwell Oxford
   Didcot  OX11 0SG
   United Kingdom

   EMail: rhys.smith@ja.net


   Margaret Wasserman
   Painless Security
   356 Abbott Street
   North Andover, MA  01845
   USA

   Phone: ++1 781 405 7464
   EMail: mrw@painless-security.com







Howlett, et al.        Expires September 12, 2013              [Page 14]