Subject: [abfab] charter take 2

From: Leif Johansson <[email-masked]>
Date: Wed, 11 Aug 2010 15:11:40 +0200

Klaas and me have been trying to summarize feedback from the BoF in the
form of new charter text. We both felt it was necessary to rewrite most
of the text to capture all of the feedback we've gotten during and
after Maastricht. We have been very careful in capturing the essence of
the first version.

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.

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.

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

---

From: Sam Hartman <[email-masked]>
Date: Wed, 11 Aug 2010 11:01:54 -0400

I'm certainly fine with the proposed charter.

I note however that you rolled back changes made to address feedback
from Hannes.  In particular the first version of the charter I
circulated claimed that we would useSAML, EAP and AAA without
explanation why.  He gave feedback that we really needed to explain how
that came about.  Thus the more verbose text in the version of the
charter we used at the BOF.

I'm actually happy with your revisions, but you should close base with
Hannes to see where he stands.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 11 Aug 2010 17:30:25 +0200

Sam, Leif,

I like what's there.  I think Hannes' concern is obviated by the idea
that other approaches will be entertained as and when they are presented.

Eliot

On 8/11/10 5:01 PM, Sam Hartman wrote:
> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab
>

---

From: Leif Johansson <[email-masked]>
Date: Wed, 11 Aug 2010 22:10:01 +0200

> charter we used at the BOF.

I'm sorry about that. It was unintentional. I'll talk to Hannes (unless
he chooses to chime in on the list very soon).

> Hannes to see where he stands.

Great!

	Cheers Leif

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 11 Aug 2010 15:34:44 -0500

> there is no readily deployable solution for federated identity.

You might want to explain why Kerberos doesn't qualify and/or that even
if it did, it's not what's been deployed for web use, therefore it's
irrelevant.  That would help address Glen's points.

Proposed text:

   It is true that many Internet protocols can use Kerberos V5 for
   authentication.  However, Kerberos is not an authentication
   technology commonly used in Internet-scale web deployments.
   Moreover, in the Kerberos model clients contact the infrastructure,
   whereas it is highly desirable for servers to contact infrastructure
   [maybe list some reasons?].  ...

> solutions by the working group are subject to the normal IETF consensus

Is it worth mentioning SASL/GS2?  I'd think so:

   Initially the working group will focus on using GSS-API (RFC2743) and
   SASL (via the GS2 bridge to GSS-API [RFC4422] [RFC5801]) to...

Looks good to me.

Nico
--

---

From: Rafa Marin Lopez <[email-masked]>
Date: Thu, 12 Aug 2010 00:08:07 +0200

Hi Nico, 

> irrelevant.  That would help address Glen's points.

[Rafa] In my opinion, we should	not explicitly prohibit/restrict Kerberos (or, in general, any other potential solution/alternative) from the beginning before deeper analysis. For example, AFAIK (please, correct if I am wrong) GSS-API implementations usually work based on Kerberos tickets and are deployed in precisely protocols not based on HTTP/HTML.

If after further analysis Kerberos must be discarded, we can do so.

Best regards.

-------------------------------------------------------
Rafael Marin Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: [email-masked]
-------------------------------------------------------

---

From: Leif Johansson <[email-masked]>
Date: Thu, 12 Aug 2010 00:15:02 +0200

> If after further analysis Kerberos must be discarded, we can do so.

Rafa: there has been discussion about why Kerberos isn't obviously
suitable on the list. Can I get you to explain why in your opinion the
arguments put forward by Nico and Sam (among others) do not apply?

	Cheers Leif

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 11 Aug 2010 17:36:44 -0500

On Thu, Aug 12, 2010 at 12:08:07AM +0200, Rafa Marin Lopez wrote:
> [Rafa] In my opinion, we should	not explicitly prohibit/restrict
> Kerberos (or, in general, any other potential solution/alternative)
> from the beginning before deeper analysis. For example, AFAIK (please,
> correct if I am wrong) GSS-API implementations usually work based on
> Kerberos tickets and are deployed in precisely protocols not based on
> HTTP/HTML.
> 

Sure.  My intention is not to leave Kerberos out but to explain why
Kerberos is not enough to discard the EAP GSS + AAA + SAML approach.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 11 Aug 2010 18:22:41 -0500

Also, excluding Kerberos-based solutions from this WG's charter's does
not mean excluding Kerberos-based solutions altogether.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 11 Aug 2010 19:33:50 -0400

>>>>> "Leif" == Leif Johansson <[email-masked]> writes:

    >> Kerberos (or, in general, any other potential
    >> solution/alternative) from the beginning before deeper
    >> analysis. For example, AFAIK (please, correct if I am wrong)
    >> GSS-API implementations usually work based on Kerberos tickets
    >> and are deployed in precisely protocols not based on HTTP/HTML.
    >> 

    Leif> Rafa: there has been discussion about why Kerberos isn't
    Leif> obviously suitable on the list. Can I get you to explain why
    Leif> in your opinion the arguments put forward by Nico and Sam
    Leif> (among others) do not apply?

I find myself in agreement with Rafa.
Both Nico and I have acknowledge that more of Kerberos technology may be
appropriate in the future.

I don't see why proposals that involve more or less Kerberos technology
should face a higher or lower bar than anything else.  We have an
explanation for why Kerberos is not the answer--if someone proposed just
using Kerberos unmodified I'd agree with them.  The most likely
proposals for using Kerberos technology involve building on GSS-EAP or
taking some Kerberos concepts and adding them to EAP.

I strongly prefer the original to text to the text with Nico's suggested
modification.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 12 Aug 2010 07:41:27 +0200

Nico,

Can we please keep the charter from becoming an entire treatise of work
(moreso than it already is)?  I think it's sufficient that the IESG and
the WG know why Kerberos wasn't a starting point.

Eliot

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 12 Aug 2010 01:01:25 -0500

On Wed, Aug 11, 2010 at 03:11:40PM +0200, Leif Johansson wrote:
> [...]

Regarding UIs...  Since this work will be based on the GSS-API, and the
GSS-API lacks APIs relating to UIs...  Will GSS-API extensions relating
to UIs (say, enhancements for mechanism interaction with the user) be
pursued here, or in KITTEN WG?  Presumably the latter.  Or is this
mechanism, though a GSS-API mechanism, not to be used through GSS-API
bindings?

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 12 Aug 2010 01:09:27 -0500

> the WG know why Kerberos wasn't a starting point.

It seemed like an FAQ.  No, the charter doesn't have to go into detail
on this.  The question should be addressed somewhere that people
stumbling into this WG will find it, but that's it.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 12 Aug 2010 01:25:09 -0500

> mechanism, though a GSS-API mechanism, not to be used through GSS-API

Oh, please excuse the above late-night thinko.  As with the GSS-API
today, UIs can be invoked without the application's help in GUI
environments, and that's enough for starters.

Nico
--

---

From: Leif Johansson <[email-masked]>
Date: Thu, 12 Aug 2010 09:56:19 +0200

HTTP/HTML.
> Kerberos is not enough to discard the EAP GSS + AAA + SAML approach.

So can we leave the charter text as it is (in this respect)? In general
I think less is more when it comes to charter text.

	Cheers Leif

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 12 Aug 2010 15:04:39 +0700

What does that mean?  

Hope this helps.

 ~gwz

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Nicolas Williams
> Sent: Thursday, August 12, 2010 6:23 AM
> To: Rafa Marin Lopez
> Cc: [email-masked]
> Subject: Re: [abfab] charter take 2
>

---

From: Leif Johansson <[email-masked]>
Date: Thu, 12 Aug 2010 10:11:45 +0200

> What does that mean?  

I think Nico means that anyone is free to propose work for the IETF and
given enough support work will get done.

	Cheers Leif

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 12 Aug 2010 15:19:29 +0700

Nicolas Williams [mailto://[email-masked]] writes:

...

>    technology commonly used in Internet-scale web deployments.

Now I'm really confused!  Why does that matter?  For that matter, surely you
aren't claiming that GSS-API, (non-existent) eap-gss & RadSec (not RADIUS as
advertised) _are_ authentication technologies used in Internet-scale web
deployments?

>    [maybe list some reasons?].  ...

Maybe also what, exactly, 'servers contact infrastructure' means...

...

---

From: Klaas Wierenga <[email-masked]>
Date: Thu, 12 Aug 2010 10:20:50 +0200

On 8/12/10 9:56 AM, Leif Johansson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> HTTP/HTML.
>>>

I think it is fair to state explicitly that we don't want to paint 
ourselves in a corner wrt to the technology choices we made. We have a 
proposed starting point (GSS-API, SAML, EAP, AAA) that was met with 
rough consensus, that shouldn't stop us from discussing possible better 
solutions and adopt them if WG consensus says so.

Klaas

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 12 Aug 2010 15:22:02 +0700

> given enough support work will get done.

Just not in this particular Rube Goldberg experiment?

...

---

From: Leif Johansson <[email-masked]>
Date: Thu, 12 Aug 2010 10:31:18 +0200

> Just not in this particular Rube Goldberg experiment?

I mean that the normal IETF consensus process applies to this WG as to
any other part of the IETF.

If you feel that that needs to be made explicit in the charter then by
all means let us do so.

	Cheers Leif

---

From: Sam Hartman <[email-masked]>
Date: Thu, 12 Aug 2010 08:35:23 -0400

>>>>> "Klaas" == Klaas Wierenga <[email-masked]> writes:

    Klaas> On 8/12/10 9:56 AM, Leif Johansson wrote:
    >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
    >> 
    >> HTTP/HTML.
    >>>> 
    >>> Sure.  My intention is not to leave Kerberos out but to explain
    >>> why Kerberos is not enough to discard the EAP GSS + AAA + SAML
    >>> approach.
    >> 
    >> So can we leave the charter text as it is (in this respect)? In
    >> general I think less is more when it comes to charter text.

    Klaas> I think it is fair to state explicitly that we don't want to
    Klaas> paint ourselves in a corner wrt to the technology choices we
    Klaas> made. We have a proposed starting point (GSS-API, SAML, EAP,
    Klaas> AAA) that was met with rough consensus, that shouldn't stop
    Klaas> us from discussing possible better solutions and adopt them
    Klaas> if WG consensus says so.

I think the current charter proposal does that and does a good job of
drawing the line at changes requiring a recharter.

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Thu, 12 Aug 2010 08:37:38 -0400

>>>>> "Glen" == Glen Zorn <[email-masked]> writes:

    Glen> Leif Johansson [mailto://[email-masked]] writes:
    >> I think Nico means that anyone is free to propose work for the
    >> IETF and given enough support work will get done.

    Glen> Just not in this particular Rube Goldberg experiment?

Well, an outcome of a BOF or WG discussion could be a decision to try
and recharter an existing WG.  But yes, the charter is intended to scope
the work of abfab.

--Sam

---

From: Klaas Wierenga <[email-masked]>
Date: Thu, 12 Aug 2010 14:42:38 +0200

On 8/12/10 2:35 PM, Sam Hartman wrote:
>>>>>> "Klaas" == Klaas Wierenga<[email-masked]>  writes:
>

well, the discussion on the list suggests that this is not as evident as 
also I thought it was, so I think there is no harm in making it more 
explicit.

Klaas

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 12 Aug 2010 08:54:15 -0700

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.

> 3748) and AAA (RADIUS, Diameter).

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.

> solutions by the working group are subject to the normal IETF consensus

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

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

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

> working group will emphasize this possibility of change.

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

> Coordination with other SDOs

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

> authentication within the application

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

> * Informational descriptions of usability and user-interface concerns

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

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 12 Aug 2010 10:59:25 -0500

On Thu, Aug 12, 2010 at 03:04:39PM +0700, Glen Zorn wrote:
> Nico> Also, excluding Kerberos-based solutions from this WG's
> Nico> charter's does not mean excluding Kerberos-based solutions
> Nico> altogether.
> 
> What does that mean?  

It means that one can pursue Kerberos-based solutions as either
individual submission I-Ds or in other WGs or by chartering a new WG.

For example, new pre-authentication mechanisms for Kerberos belong in
KRB-WG.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Thu, 12 Aug 2010 13:32:44 -0400

>>>>> "Dave" == Dave CROCKER <[email-masked]> writes:

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

Dave, what we were trying to choose was that the set of documents listed
as starting points would be accepted as WG items as part of the
chartering process with the effect that it would require a consensus
decision of the WG to change these documents.
I think that is a clear thing to choose; I also believe that to the best
of my understanding, it aligns with option B above, so I think we're on
the same page.
There's one document (draft-howlett-radsec-kmp) that is being submitted
as input, but that we believe additional discussion is required before
the WG decides whether to adopt that document.
I believe that's called out in the charter.

I think this is all clear in the charter--I think the debate has mostly
been over whether these are the right choices.
However text is more clear to those who have been involved. If you think
it is unclear, we should fix that.

    Dave> 3. Although it isn't followed very well, there's a directive
    Dave> for formulating the first paragraph of a charter, since that
    Dave> one paragraph is circulated separately, such as in the
    Dave> announcement of the working group.[1] 

You learn something new every day.  I bet I'm not the only former IESG member
who was unaware of this.
    Dave> paragraph with something like:

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

This seems reasonable.

--Sam

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 12 Aug 2010 14:46:50 -0700

Sam,

On 8/12/2010 10:32 AM, Sam Hartman wrote:
>      Dave>  include a compelling statement of efficacy.
...
> of my understanding, it aligns with option B above, so I think we're on

Let me stress that model b is quite different from model d.  Model b invites 
debate about the approach being taken and the solutions being proposed. 
Depending upon the problem- and solution-spaces, such debate -- especially in 
the extended form that I think is likely here -- can be healthy or detrimental.

My own view is that it's healthy when one or both spaces are not 
well-understood, since it will tend to force everyone to develop a better and 
better-shared understanding.  If things are already well-understood, this sort 
of open-ended invitation for alternatives is going to be more problematic than 
helpful.  The folks on the losing side will constantly look for a way to re-open 
the choices.

Security does not have a great track record in the IETF.  (To be fair, Internet 
scale security doesn't have a great track record anywhere.)  At Internet scale, 
point-to-point data protection is finally well established.  Anything having 
serious use of identity information is not.  At Internet scale, identity and 
authorization have already demonstrated that they constitute a very messy topic 
in which technical progress is challenging to make, and that even coherent 
discussion is often challenging.

That's why I'm pressing so hard to have the charter be especially clear, 
constrained and firm.  An effort like this needs as much help as possible to 
increase its chance of success.  If successful, it is likely to make a major 
change in the way the Internet is used.  Since we really do need that change, 
that extra help is not for whimsy or ego.

If the folks formulating the proposal that the current work is based on intended 
it merely as an exemplar, with a goal of inviting proposals from the community, 
that's fine.  It won't be efficient or quick, but it's certainly a reasonable goal.

I didn't get the impression that that was the goal of this work.  Rather, I got 
the impression that the proposal is meant as a complete solution, and that the 
purpose of the working group is for refinement and, perhaps, enhancement. 
That's a completely different goal.  It, too, is reasonable.

The charter should clearly and forcefully state the goal -- in these kinds of 
terms -- and should include whatever procedural constraints are appropriate to 
that goal.  I'll state that I think what you've said in your reply does not 
match what I took to be the actual view about the work that's been submitted.  I 
think that what you've said is more flexible than is intended by the team that 
developed the proposal.

At the least, it will be good to get that clarified.

The clarification may well require being more firm and forthright than is 
comfortable for some folks.  I'll suggest that that bit of discomfort can at 
best be delayed, but not avoided.  Suffer it now or suffer it -- probably worse 
-- later.

> been over whether these are the right choices.

Much of what I heard in the BOF was not "here's a specific technical or 
operational problem with a specific part of the proposal" or "here's an 
alternative that has the following superior characteristics."  Rather I heard 
"the group should also consider proposal X or mechanism Y."

I'm sorry, but that sort of open-ended suggestion is much more appropriate to 
the situation I cited earlier, when the problems and their solutions are not 
(yet) all that well understood.   Unless I've misunderstood things, that's not 
the case here.

> You learn something new every day.  I bet I'm not the only former IESG member

Unfortunately, I've tested that a few times over the years and you are correct.

On the average, the IETF is quite good at creating procedural text and quite 
poor at following it.  Following it requires quite a bit of extra work...

d/

-- 

   Dave Crocker

---

From: Melinda Shore <[email-masked]>
Date: Thu, 12 Aug 2010 14:02:48 -0800

On Aug 12, 2010, at 1:46 PM, Dave CROCKER wrote:
> My own view is that it's healthy when one or both spaces are not well-understood, since it will tend to force everyone to develop a better and better-shared understanding.  If things are already well-understood, this sort of open-ended invitation for alternatives is going to be more problematic than helpful.  The folks on the losing side will constantly look for a way to re-open the choices.

I was extremely unhappy with the BOF - discussion of
alternatives was shut down, there was substantial dissent
on a consensus call but consensus was declared anyway
with dissenters not given an opportunity to speak up, and
several other problems.  But, I think Dave's point here is
compelling, and it's not that hard to come up with efforts
that have been derailed by constant revisitation of key
decisions.  I tend to think it's not going to be possible
to finalize the charter if there's an attempt to pay lip
service to being open to alternatives when that openness
is actually just procedural, to keep people happy with the
process, and not technical.  

It seems to me that some of the key decisions here were
made before the work was brought to the IETF, and that
even though I may or may not disagree with some of them,
probably what needs to be done here is to nail down those
decisions, document them, and get them into the charter.

Melinda

---

From: Sam Hartman <[email-masked]>
Date: Thu, 12 Aug 2010 18:13:51 -0400

Dave, I think what we (speaking as one of the authors of the proposal
want) is:

* Agree that we're going to start with our proposal as a work item of
  the WG.  That means you need active agreement to change the proposal.

* Put some explicit constraints about technology choice etc into the
  charter, so that if we succeed we get something that is fundamentally
  similar to our proposal.

* Leave the WG a lot of flexibility with the details of our proposal.

* Be open to the idea that it might also be good to work on other
  proposals that are either extensions of our proposal, solve different
  problems, etc. However taking on such a proposal should involve a
  recharter so we can have an explicit point to discuss whether the
  proposals we are considering adding are good ideas. We'd also
  presumably want to discuss whether the existing WG is the right place
  to work on them. We'd presumably consider issues like whether we're
  taking on too much, whether we can deliver quality results in a timely
  manner with the things we're considering signing up to do, and whether
  we have the right people.

I believe that constraining the technologies and their roles is
sufficient to avoid constant discussion of what approach we're going
down. In particular, I believe that if we say we're using EAP to
authenticate the subject to a trusted party, using AAA to authenticate
and convey information from that party to a relying party, using SAML
for authorization and personalization, and using GSS-API for application
integration, we have fundamentally captured sufficient constraints.

I'd definitely appreciate help saying that in the charter. Also, I'm
certainly open to comments about whether that's the wrong thing to say.

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 12 Aug 2010 15:16:22 -0700

> certainly open to comments about whether that's the wrong thing to say.

I'd like to emphasize that the second sentence should be the highest priority in 
writing the charter.

Get consensus on that and the rest is mere wordsmithing.

d/
-- 

   Dave Crocker

---

From: Leif Johansson <[email-masked]>
Date: Fri, 13 Aug 2010 00:39:47 +0200

On 08/13/2010 12:16 AM, Dave CROCKER wrote:
> I'd like to emphasize that the second sentence should be the highest
> priority in writing the charter.

I know you said this at the mic during the BoF: clearly list the points
of least flexibility in the proposal. I believe this is what Sam is
trying to do by saying:

"I believe that constraining the technologies and their roles is
sufficient to avoid constant discussion of what approach we're going
down. In particular, I believe that if we say we're using EAP to
authenticate the subject to a trusted party, using AAA to authenticate
and convey information from that party to a relying party, using SAML
for authorization and personalization, and using GSS-API for application
integration, we have fundamentally captured sufficient constraints."

Are we just in violent agreement?

I agree we need consensus on this point: is the community willing to
support formation of a WG with these constraints and I'd like to get
to a point in the charter process where we can ask that question.

	Cheers Leif

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 12 Aug 2010 17:53:07 -0500

On Fri, Aug 13, 2010 at 12:39:47AM +0200, Leif Johansson wrote:
> [...]"

I am.

Incidentally, and for the record, I have no direct nor indirect interest
in any one of the proposals made here (though I am friends with some of
the proponents).  I've stated my rationale for supporting the proposal
on the table (EAP GSS + AAA + SAML).  I've also stated my rationales for
pursuing this proposal in this WG in spite of, and even to the exclusion
(in this WG) of some possible alternatives (Kerberos, ...) or others
(OAuth, ...) based on real-world applicability issues (Kerberos, ...) or
security principles (OAuth, ...).  I hope those are convincing, else
someone could convince me.  I'm open to OAuth if modified to meet the
security principles stated by Sam.

Nico
--