Re: [abfab] charter take 2

[Dave CROCKER <[e-mail]>]

Folks,

Having read the thread so far, there are a number of items I suggest be changed 
in the charter:


1.  What is "federated identity"?  The charter does not define it. I take a 
rough guess, as part of some text below.  It's mostly meant as a placeholder, so 
that those of you working on this will replace it will what you really want/mean.


2.  When a charter scopes its work and there has been prior work, the charter 
needs to make an explicit and firm statement of the role of that work.  The 
usual choices are:

     a.  A specified set of prior work is input to discussion, but the solution 
space is wide open.

     b.  A specified set of prior work will be given preference, but the working 
group is entirely free to replace it or any component of it.  (The meaning of 
"preference" is perhaps intentionally vague.)

     c.  A specified set of prior work provides the foundation for the solution 
specification, but changes and alternatives will be permitted, given a strong 
benefit in function, performance and/or operation.

     d.  A specified set of prior work is specifies the core of the solution. 
Changes will be permitted only when a compelling problem or requirement dictates it.

     There are, perhaps, more choices, but defines the arc.  Especially with the 
debate from the BOF and continuing on this thread, the charter needs to choose 
among these.  The proposed work does, in fact, have a proposed solution. The 
third paragraph states it and later in the charter the specific draft documents 
are cited. Specify their precise role, relative to making changes.  Otherwise it 
is going to continue to be peppered with these foundational debates.  To the 
extent that alternative solutions are permitted, the charter needs to make very 
clear what the criteria for replacement will be.

     I don't have a technical assessment of the offered set of specifications, 
but I know that they are well-established and well-deployed and that starting 
with that sort of base puts a working group far ahead of things, particularly in 
a problem space that is, well, problematic.  In case anyone had not already 
known, the debate surrounding the BOF and this thread make clear that this 
effort is in a problematic problem space.  Or perhaps more accurately, a 
problematic solution space.

     To that end, I suggest choosing alternative d, above.  When someone 
proposes a change, they need to be required to include a compelling statement of 
efficacy.  It should not be enough to call for "considering" an alternative.  It 
needs to be required that the alternative be offered as superior and the case 
for its superiority stated.


3. Although it isn't followed very well, there's a directive for formulating the 
first paragraph of a charter, since that one paragraph is circulated separately, 
such as in the announcement of the working group.[1]  The directive really 
specifies that the paragraph be a summary abstract, giving folks a basic sense 
of the problem to be tackled, its relevance, and some indication of how it will 
be solved.  Besides being formally required, I find such summary paragraphs 
useful as an indication of how well a working group understands what it is going 
to.  It isn't easy to write a tight, one-paragraph summary of work that's to be 
done, so that it's clear and reasonably compelling.

    To that end, I suggest, replacing the existing first paragraph with 
something like:

    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 and 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.


Some additional comments:


> Abfab Proposed Charter
>
> Abfab - Application Bridging for Federated Access Beyond web
>
> Federated identity is today widely deployed for web applications using
> such technologies as OpenID, Security Assertion Markup Language (SAML),
> OAuth and Information Card (IMI). However, for protocols such as
> IMAP, XMPP, SSH, NFS and other non-IETF protocols not based on HTTP/HTML
> there is no readily deployable solution for federated identity.
>
> 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).
>
> Constraints:
> - ------------
>
> The working group will ensure that any solution developed has built-
> in technical controls for privacy protection.

No doubt I'm naive, but I don't really know what that means.  "privacy 
protection" is a remarkably vague term, in real world usage. I suggest a second 
sentence to explain it, in practical terms.  Does it mean encryption?  I assume 
the goal is more interesting than that.


> Initially the working group will focus on using GSS-API (RFC2743) to
> integrate federated identity into application protocols but other
> technologies for application interface are in scope. Adoption of such
> solutions by the working group are subject to the normal IETF consensus
> and (re)charter process.

This bit of flexibility is an opportunity to sink the working group.  GSS-API 
has a difficult enough history, without inviting more painful and unproductive 
debate.  If there is already a candidate choice, name it.  If there isn't, you 
are almost certainly in the realm of research, not engineering.


> 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.

What is the difference between "change EAP" versus "development of EAP 
mechanisms"?  Does the latter mean "designs that use EAP"?

Are there any goals or constraints to the types of changes that will be 
permitted?  Since these are deployed protocols, changes could be extremely 
disruptive.  An example clarification could be that changes will be upward 
compatible, to protect the installed based.  Certainly some comment about 
possible effects on the installed base for the constituent protocols needs to be 
made.


> 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

Here's where to insert explicit language about the role of these drafts.  It 
should be written as a contract to permit or prohibit classes of changes or 
replacements.


> 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.


Both the topic of identity and the topic of usability are open invitations to 
wander forever and unpleasantly in a land of controversy and confusion.  Worse, 
as a community, the IETF has a long history of very low competence in usability 
discussions. Very few participants have a background in UI/UXE/usability designs 
and the required methodologies for validating them.  This is a specialty but it 
is rarely acknowledged as such in IETF discussions. For example, virtually all 
discussions of usability that I've seen in the IETF are based on using the 
speaker as an exemplar.  No one participating in the IETF is an example of a 
typical user.

If the group still insists on this charter item, it needs to explain how it will 
pursue such issues productively.


> 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.

What does that last sentence actually mean, in practical terms?


> 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

Application authentication?  Doesn't this mean application /user/ 
authentication?  Does it also mean authorization?


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

"solution"?  Is that different from a specification?  What will this be, 
exactly?  How is it expected to be used?


> * 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

Thar be dragons.

d/


[1] <http://www.ietf.org/rfc/rfc2418.txt>, Section 2.2:

>    Description of working group
>       The focus and intent of the group shall be set forth briefly. By
>       reading this section alone, an individual should be able to decide
>       whether this group is relevant to their own work. The first
>       paragraph must give a brief summary of the problem area, basis,
>       goal(s) and approach(es) planned for the working group.  This
>       paragraph can be used as an overview of the working group's
>       effort.

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net