[abfab] charter take 3

[Leif Johansson <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


I've tried my best to summarize the various threads going on, specifically:

- - I've used Daves excellent first paragraph (with minor nit)
- - I've used Sams text describing the role of EAP, AAA and SAML (3rd p.)
- - I've added a paragraph (4th) where I've tried to be explicit (in the
light of the discussion between Sam, Glen, Dave and Klaas) about the
status of EAP, AAA and SAML in the architecture.
- - Minor stylistic nit in 5th p.

Abfab Proposed Charter

Abfab - Application Bridging for Federated Access Beyond web

Federated identity shares user authorization information among
organizations, without specific registration of the individual user at
the organization controlling a a remote resource.  A number of such
mechanisms are in use for the Web.  This working group will specify a
federated identity mechanism for use by other Internet services, such as
IMAP, XMPP, SSH, NFS and other non-IETF protocols, not based on Web
protocols.  The design will combine existing IETF protocols,
specifically SAML, EAP (RFC 3748) and AAA (RADIUS, Diameter).  With the
deployment of the solution, a user from one organization will be able to
access resources at another organization, given only prior agreement
between the organizations, or prior agreement between each organization
and a trusted intermediary.

While work continues elsewhere on basic mechanisms that rely on using an
HTTP/HTML interface to authenticate and authorize non-web applications,
this working group will look at approaches that do not rely on the web,
taking into account user interface concerns and the need to pass
structured data to an appropriate authentication interface, as well as
the need to handle large scale discovery.

The working group will develop a solution for federated identity for
IETF and non-IETF application protocols by combining SAML, EAP (RFC
3748) and AAA (RADIUS, Diameter). Specifically EAP will be used to
authenticate the subject to a trusted party, AAA (RADIUS and Diameter)
will be used to authenticate and convey information from that party to a
relying party and SAML is used for authorization and personalization.

The working group may consider other alternative technology for these
three roles in the architecture but any change in direction in this
respect requires rechartering of the working group.

Constraints:
- ------------

Initially the working group will focus on using GSS-API (RFC2743) as
a mechanism for integrating the developed solution for federated
identity into application protocols but other technologies for
application interface are in scope of the working group and may be
adopted as deliverables subject to the normal IETF consensus and
(re)charter process.

The working group will ensure that any solution developed has built-
in technical controls for privacy protection.

The working group may not change EAP (beyond the development of EAP
mechanisms), RADIUS or Diameter without establishing consensus with
the appropriate community within the IETF.

The working group will use the following documents as a starting
point for its work:

- - draft-howlett-eap-gss-00,
- - draft-howlett-radius-saml-attr-00
- - draft-hartman-gss-eap-naming-00

Concerns have been raised that additional work is required in keying
AAA associations in a federated environment. The working group is
chartered to explore these concerns and if needed, specify protocols
that use existing AAA key management mechanisms to address these concerns.

In addition, the working group will explore the usability and user
interface issues associated with federated authentication. The work is
not chartered to standardize protocols or recommend best current
practice in the area of usability. The working group should explore
the area and produce informational documents describing the issues and
recommending appropriate work for the IETF in this area.

As future work in dealing with user interface in this area progresses,
the architecture of the system may need to expand to include additional
components or make significant changes to adapt to improvements in
understanding of user interface. In describing architecture work, the
working group will emphasize this possibility of change.

Coordination with other SDOs
- ----------------------------

This work will require close coordination with work going on in the
OASIS Security Services Technical Committee (SSTC). There should be
sufficient overlapping participation between the SSTC and this working
group for informal coordination. The chairs of this working group may
work with the SSTC chairs and the IAB in case formal coordination is
required.

In particular coordination is required with respect to the SAML-RADIUS
binding.

Deliverables
- ------------

The deliverables of the working group are:

* A document describing applicable use cases.

* An architecture document describing how the components of the solution
fit together to address the use cases and open issues that will require
future changes to the architecture

* A standards-track protocol for carrying SAML messages in RADIUS and
Diameter

* An update to the EAP applicability statement in RFC 3748 describing
the applicability of EAP to application authentication and placing
appropriate requirements on this new EAP use case

* A standards track solution for using EAP methods to provide
authentication within the application

* An update to the EMSK root key applicability statement in RFC 5295

* A standards-track description of GSS names and name attributes
required by the solution

* Informational descriptions of usability and user-interface concerns
related to this work

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxk9RAACgkQ8Jx8FtbMZnc5sACgjZA9qFQLI9PWajoNF5DXWj/O
4NQAnidUYYfyrcoOqvgfFeGRURQ1wh48
=gRBO
-----END PGP SIGNATURE-----