Subject: [abfab] charter take 3

From: Leif Johansson <[email-masked]>
Date: Fri, 13 Aug 2010 09:32:38 +0200

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

---

From: Eliot Lear <[email-masked]>
Date: Fri, 13 Aug 2010 11:39:32 +0200

Excellent, Leif.

I have small suggestions, but I would be happy with this charter if it
went forward.  In general, this follows my view that charters should be
as succinct as necessary, but (to borrow from Einstein) no more so.

Please see below.

On 8/13/10 9:32 AM, Leif Johansson wrote:

> the appropriate community within the IETF.

s/^T/Other than a change to its applicability statement, t/

> working group will emphasize this possibility of change.

Having been the instigator of these paragraphs, I suggest they be
removed.  Having thought more about it, while I still have substantial
UI concerns, I think NOT saying this in the charter is the same as
saying it in the charter, so why bother if the result is the same?  Or
in the alternative, simply reduce to the following:

As practical experience and research dictate, the group will document
user interface/usability issues that may have impact on the protocol(s)
being developed.

> ----------------------------

Change to the following:

The Working Group will work in conjunction with the IAB to establish
appropriate liaison relationships with OASIS and take care that any
changes or profiling required in SAML can be properly coordinated across
the different organizations.
--

This should address David's concern while leaving open the possibility
that the existing profiles will be suitable (I don't think we've gotten
to the point of understanding this yet).

---

From: Josh Howlett <[email-masked]>
Date: Fri, 13 Aug 2010 09:45:09 +0000

Leif,

Looking good; one minor comment:

> the organization controlling a a remote resource.

Authorisation is only one application of federated identity, and I also think we could be more explicit about the benefits of federated identity. I suggest words to the effect of:

"Federated identity is concerned with the controlled sharing of information about principals, commonly across organisational boundaries. This avoids the redundant registration of principals who operate in multiple domains reducing administrative overheads (e.g., by simplifying user account management) and improving usability (e.g., by reducing the number of credentials issued to user principals). It may also prevent the unnecessary exposure of user principal information that might be subject to privacy concerns and, depending on jurisdiction, regulatory or statutory control. This information may be used for purposes such as authorisation (i.e., for access to a service) and personalisation (e.g., for customising a principal's experience of the service).

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: Leif Johansson <[email-masked]>
Date: Fri, 13 Aug 2010 12:41:42 +0200

> the different organizations.

Personally I think your modifications are good as they make the charter
more readable. Unless I hear opposition I'm inclined to apply them.

	Cheers Leif

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Fri, 13 Aug 2010 14:00:35 +0300

Hi Lef, 

Thanks for getting this going. A few minor comments. 

> the organization controlling a a remote resource.

I am trying to parse this sentence and I does not make sense to me. 

First, I think you are trying to say "Federated Identity Management
Systems share"
(let's assume that such a term exists somewhere)

Second, "share ... User identity information and related attributes" 

(you see that the terminology document that I distributed recently would
reallly be useful)

What does it mean to say "without specific registration of the
individual user at
> the organization controlling a a remote resource."

  A number of such
> protocols.

Which non-IETF protocols? 
I would you would say non-HTTP based protocols. 

  The design will combine existing IETF protocols,
> specifically SAML, EAP (RFC 3748) and AAA (RADIUS, Diameter). 

SAML is not an IETF protocol. 
Maybe you want to say 

"
The design will combine existing protocols, namely the Extensible
Authentication Protocol (EAP - RFC 3748), Authentication, Authorization
and Account Protocols (RADIUS - RFC 2865 and Diameter - RFC 3588), and
the Security Assertion Markup Language (SAML). 
"

(I put SAML as the last item because it is the least important one in
the approach discussed on the list. Everything would just work without
using SAML as well.)

>  With the

Authenticate and authorize users for non-HTTP based applications. 

> this working group will look at approaches that do not rely 

... On the HTTP-based web. 

> the need to handle large scale discovery.

What do you mean by passing structured data to an appropriate
authentication interface? 

> IETF and non-IETF application protocols

I would prefer to write "for non-HTTP based protocols". 

> by combining SAML, EAP (RFC
> 3748) and AAA (RADIUS, Diameter).

Btw, you said that already previously. Maybe you want to merge the text
with the previous paragraph to make it less repetitive. 

 Specifically EAP will be used to
> respect requires rechartering of the working group

... Other alternative technology for these three communication
relationships.

> Constraints:

Remove the initially 

> recommending appropriate work for the IETF in this area.

Hmmm. I am not happy with this text. Where else would you like to do
such work in the IETF other than in the group where the experts of the
technology are. Why not to work on a document that illustrates the
issues and if there are suggestions to make then just make them. 

> working group will emphasize this possibility of change.

This sounds a bit fuzzy. What do you mean by "additional components"? 
Are we talking about user interface issues or protocol extensions that
simplify operations and management (i.e. the user in the sense of the
administor of the system). 

> Coordination with other SDOs

So, what do you expect OASIS to do in this work? 
Review? 
Be aware of the IETF group? 

Because of the different organizational structure and membership model I
am always concerned when work is spread over different SDOs. I am
chairing the KEYPROV working group and we had some interactions with
OASIS and I am not sure OASIS has been helpful in any way. Why do you
think it is different here? 

> Deliverables

Sounds good to me. Are you going to propose milestones as well? 

Ciao
Hannes

---

From: Josh Howlett <[email-masked]>
Date: Fri, 13 Aug 2010 11:02:58 +0000

> "Federated identity is concerned with the controlled sharing of
> information about principals, commonly across organisational
> boundaries. This avoids the redundant registration of principals who
> operate in multiple domains reducing administrative overheads (e.g., by
> simplifying user account management) and improving usability (e.g., by
> reducing the number of credentials issued to user principals). It may
> also prevent the unnecessary exposure of user principal information
> that might be subject to privacy concerns and, depending on
> jurisdiction, regulatory or statutory control. This information may be
> used for purposes such as authorisation (i.e., for access to a service)
> and personalisation (e.g., for customising a principal's experience of
> the service).

Leif has privately suggested that this is a bit wordy; here's an abridged version:

"Federated identity facilitates the controlled sharing of information about principals, commonly across organisational boundaries. This avoids redundant registration of principals who operate in multiple domains, reducing administrative overheads and improving usability. It may also address privacy related concerns that, depending on jurisdiction, may be subject to regulatory or statutory control. This information may be used for purposes such as authorisation and personalisation."

Josh.

---

From: Leif Johansson <[email-masked]>
Date: Fri, 13 Aug 2010 13:17:04 +0200

> "Federated identity facilitates the controlled sharing of information about principals, commonly across organisational boundaries. This avoids redundant registration of principals who operate in mu…

Josh - was this meant to replace the entire first paragraph?

	Cheers Leif

---

From: Leif Johansson <[email-masked]>
Date: Fri, 13 Aug 2010 13:29:30 +0200

>> the organization controlling a a remote resource."

Actually it was Daves paragraph but I suggest you comment on the version
Josh just suggested for the first paragraph. It might parse more easily.

On this note I urge everyone not to bike-shed on an explanation of what
constitutes federated identity. We have plenty of time for that _if_ we
can get to a point where we can talk about working group documents ;-)

> I would you would say non-HTTP based protocols. 

There are plenty of protocols not done in the IETF but I take your point
and will try to polish that up a bit.

> SAML is not an IETF protocol. 

god point.

> the Security Assertion Markup Language (SAML). 

yes.

> the approach discussed on the list. Everything would just work without

That aside think your version reads better.

> ... On the HTTP-based web. 

Imho that would be silly. Everyone knows the web runs on HTTP.

> authentication interface? 

Elliot has suggested dropping those paragraphs actually...

> with the previous paragraph to make it less repetitive. 

possibly.

>> Initially the working group will focus on using GSS-API (RFC2743) as

Why? There has been lots of discussion on the list about the need to
allow for future introduction of new application interface technologies
but that the WG would start with GSS-API. Initially is meant to convey
precisely this and I've not heard any opposition to it so it stays
unless I hear lots more support for dropping it.

> issues and if there are suggestions to make then just make them. 

I presume you are talking about the last paragraph and not all three?
In that case Elliot has suggested dropping that text already (he was
the originator of the usability concerns).

> administor of the system). 

See above wrt Elliots suggestions.

> Be aware of the IETF group? 

Does that have to go in the charter?

> Sounds good to me. Are you going to propose milestones as well? 

I think we have to before Sean would be happy :-)

	Cheers Leif

---

From: Leif Johansson <[email-masked]>
Date: Fri, 13 Aug 2010 13:43:25 +0200

> Elliot has suggested dropping those paragraphs actually...

Actually I'm wrong. Elliot suggested dropping the usability paragraphs,
not this one. Perhaps Klaas can provide some insight as he was the
originator of that paragraph.

	Cheers Leif

---

From: Josh Howlett <[email-masked]>
Date: Fri, 13 Aug 2010 13:01:53 +0000

> > "Federated identity facilitates the controlled sharing of information about
> principals, commonly across organisational boundaries. This avoids redundant
> registration of principals who operate in multiple domains, reducing
> administrative overheads and improving usability. It may also address privacy
> related concerns that, depending on jurisdiction, may be subject to regulatory
> or statutory control. This information may be used for purposes such as
> authorisation and personalisation."
> >
> 

Err, the first and last sentence of the first paragraph - not very helpful. Let me try again:

"Federated identity facilitates the controlled sharing of information about principals, commonly across organisational boundaries. This avoids redundant registration of principals who operate in multiple domains, reducing administrative overheads and improving usability while addressing privacy-related concerns and regulatory and statutory requirements of some jurisdictions. 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 EAP (RFC 3748) and AAA (RADIUS, Diameter) with SAML. This combination may be used for purposes such as authorisation and personalisation."

Josh.

---

From: Leif Johansson <[email-masked]>
Date: Fri, 13 Aug 2010 15:41:30 +0200

> "Federated identity facilitates the controlled sharing of information about principals, commonly across organisational boundaries. This avoids redundant registration of principals who operate in mu…

OK combining that with Hannes suggestion about "non-HTTP based
protocols" should give us a winner I hope. Thanks!

	Cheers Leif

---

From: "Scott Cantor" <[email-masked]>
Date: Fri, 13 Aug 2010 11:04:21 -0400

> ... On the HTTP-based web.

Is there a non-HTTP-based web?

Perhaps it's better to say "do not rely on HTTP".

> authentication interface?

I think this is talking about the fact that it's not an HTML-based user
interface, so the entity doing the credentials collection is not on the
server side and doesn't have control over the UI. The Cardspace problem,
essentially.

> think it is different here?

OASIS is a collection of TCs without any real ties amongst them beyond
superficial ones. The results you get will depend on the TC you're dealing
with.

-- Scott

---

From: Sam Hartman <[email-masked]>
Date: Fri, 13 Aug 2010 12:19:58 -0400

Leif, I think your charter take 3 is fine, with one exception.

I object fairly strongly to the fourth paragraph--the one that says we
are open to changing direction with a recharter.  Obviously, any WG can
be rechartered--krb-wg could take on DHCP maintinance with a successful
recharter.  However, I think going as far as you do in the charter
invites exactly the sort of endless spinning Dave warns about.  I feel
fairly strongly that paragraph should be removed.

To the extent we want to explicitly encourage flexibility, we do below.

--Sam

---

From: Leif Johansson <[email-masked]>
Date: Fri, 13 Aug 2010 20:13:57 +0200

> To the extent we want to explicitly encourage flexibility, we do below.

To tell the truth I was actually a bit iffy about that sentence myself
but perhaps I went overboard in my efforts to making things explicit.

Obviously there will be a take 4 with some nits here and there and
unless I hear strong support for that sentence it goes.

	Cheers Leif

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 13 Aug 2010 11:34:42 -0700

Leif,

The charter looks much better.  I've still got a few questions, but now they are 
relatively narrow and specific:

> HTTP/HTML interface to authenticate and authorize non-web applications,

As noted (or at least implied) by another posting this morning, perhaps this 
should simply say:

      ...that rely on using an HTTP/HTML interface for authentication and 
authorization...

> the need to handle large scale discovery.

On reflection, I'm not clear what the purpose of citing the outside work is.

The more I re-read this second paragraph, the more I believe it adds no value. 
I suggest simply deleting it.

> relying party and SAML is used for authorization and personalization.

IF there is a practical import to citing "non-IETF" applications, I don't know 
what it is.  The charter should either make that real in technical or process 
terms, or it should delete the reference to the 'homes' of application 
specifications.

So, I suggest:

     The working group will specify a federated identity service for use by 
applications, by combining...

> respect requires rechartering of the working group.

I typically dislike references to hypothetical futures and especially to things 
that might be considered but which will require rechartering.

In this case, however, I think it defines a high barrier for replacing the 
technical components and it hits the reader in the face with how much effort it 
will take to climb the barrier.  So, I like it.

> Constraints:

    developed solution for federated identity
    ->
    federated identity service

(yes, this is the second placed I'm suggesting moving from 'solution' to 
'service' and using somewhat more direct language.  i think it makes a 
difference to the reading.)

> in technical controls for privacy protection.

I still have no idea what this means either conceptually or in terms of working 
group work.

> - - draft-hartman-gss-eap-naming-00

I'm pretty sure these are more than "starting points". That's a pretty vague 
term and I think you folks intend something more specific and that it means 
significant constraints on the changes to these specification that are 
considered permissible.

These are the base specifications.  What are the criteria for making changes to 
them?

That's what the charter should say, unless you folks have a different intent.

> -----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-----
> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab
>

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Leif Johansson <[email-masked]>
Date: Fri, 13 Aug 2010 20:44:11 +0200

Thanks for the review, Dave. You made some good points.

<snip>

> I typically dislike references to hypothetical futures and especially to
> things that might be considered but which will require rechartering.
> 
> In this case, however, I think it defines a high barrier for replacing
> the technical components and it hits the reader in the face with how
> much effort it will take to climb the barrier.  So, I like it.
> 

I think you and Sam will have to slug it out on this topic. He wants to
cut it. I'm iffy. You want to keep it but also cut it. Maybe somebody
else has yet another approach :-)

<snip>

> I'm pretty sure these are more than "starting points". That's a pretty
> vague term and I think you folks intend something more specific and that
> it means significant constraints on the changes to these specification
> that are considered permissible.

They are (imho) starting-points within the constraints of the
technology choices which have been outlined in the charter so I
think it is appropriate to say "starting point" in this case and
given that one has read the charter and the drafts I believe the
meaning is clear:  that given the roles of SAML, EAP and AAA
these three documents are starting points for each part of the
solution.

> 
> These are the base specifications.  What are the criteria for making
> changes to them?
> 

Normal IETF WG consensus, but we really can't keep repeating that.

	Cheers Leif

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 13 Aug 2010 11:56:47 -0700

> else has yet another approach :-)

The charter really needs to state fairly clearly what the boundaries of change 
are, within the charter.  It needs to state it forcefully enough to be useful 
when someone starts distracting the working group with calls for changes that 
really go beyond what the working group intends.  This is a question of clarity 
about what the working group intends and strong enough language in the charter 
to be used as an enforcement club.  I'd say that there is already plenty of 
demonstrated need for such a paragraph.

As for Sam vs. me, no.  Neither of us should matter that much.  That's what 
rough consensus is all about.

> these three documents are starting points for each part of the

starting points for discussion?  starting points for specification?  starting 
points for refinement?  but the actual choices can be anything?  whole new 
specifications will be acceptable?

> Normal IETF WG consensus, but we really can't keep repeating that.

What are the criteria that permits a working group chair to declare a topic out 
of scope?

Most wg chairs are nice folk who tend to let things go more astray than one 
would later have wished.  Clear and firm criteria in a charter make the wg 
chair's job much clearer about scope and therefore easier to enforce.  The 
alternative is constantly having to pool the wg for rough consensus about scope 
issue, after scope issue.

d/
-- 

   Dave Crocker

---

From: Leif Johansson <[email-masked]>
Date: Fri, 13 Aug 2010 20:58:59 +0200

On 08/13/2010 08:56 PM, Dave CROCKER wrote:
> starting points for discussion?  starting points for specification? 
> starting points for refinement?  but the actual choices can be
> anything?  whole new specifications will be acceptable?

Yes

---

From: Leif Johansson <[email-masked]>
Date: Fri, 13 Aug 2010 21:19:21 +0200

On 08/13/2010 08:56 PM, Dave CROCKER wrote:
> The charter really needs to state fairly clearly what the boundaries of
> change are, within the charter.  It needs to state it forcefully enough
> to be useful when someone starts distracting the working group with
> calls for changes that really go beyond what the working group intends. 
> This is a question of clarity about what the working group intends and
> strong enough language in the charter to be used as an enforcement
> club.  I'd say that there is already plenty of demonstrated need for
> such a paragraph.

The argument against is of course that it is redundant and that the IETF
process states that you must always have consensus. So given that the
scope is clearly expressed, what is the use of a paragraph saying
exactly what the IETF process already tells you must happen?

	Cheers Leif

---

From: Klaas Wierenga <[email-masked]>
Date: Fri, 13 Aug 2010 21:54:05 +0200

Sent from my iPad

On Aug 13, 2010, at 9:19 PM, "Leif Johansson" <[email-masked]> wrote:

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

Well, I think the argument is that some WGs have a clear exploratory phase in which all options are still at the table, whereas we don't want to be stalled by endless discussions about alternative solutions that have no demonstrable benefit, so we might as well raise the barrier explicit. I know that I have argued for a less restrictive charter before, but Dave and others have convinced me that it is important that we have a pretty tight charter. So whereas there is always the option to recharter in the IETF process, it doesn't hurt to make it clear that we are not willing to consider one of the many alternatives out there unless there is a well stated benefit, beyond "have you considered protocol X or solution Y?".

Klaas
  
> iEYEARECAAYFAkxlmrkACgkQ8Jx8FtbMZne9MQCgqjAbfd1s6bTKKjdVh+sC9QnY
> Sl0AoI8qe9hAg6RKh7+deYmeP9iRQHtR
> =xv0f

---

From: Leif Johansson <[email-masked]>
Date: Fri, 13 Aug 2010 22:05:16 +0200

>> Well, I think the argument is that some WGs have a clear exploratory phase in which all options are still at the table, whereas we don't want to be stalled by endless discussions about alternative…

Yeah I get that we need tight scoping and I think we have consensus on
that point by now.

What I'm (and I think Sam) wondering is why, if we say "we use X" we
also need to say "in order to change X to Y you need IETF consensus
and a recharter". Isn't that last bit _always_ redundant in the IETF?

However I don't care that much about this and am happy with a bit of
redundancy if it makes people happy.

	Cheers Leif

---

From: Klaas Wierenga <[email-masked]>
Date: Fri, 13 Aug 2010 22:41:08 +0200

I guess my liking of chatty protocols shows ;-) If it doesn't hurt having it in and it makes people happy, let's do that. 

Klaas

Sent from my iPad

On Aug 13, 2010, at 10:06 PM, "Leif Johansson" <[email-masked]> wrote:

> iEYEARECAAYFAkxlpXsACgkQ8Jx8FtbMZneWeQCdELSh46rIxq21BrGYS0N7Coss
> W+8AoMCHUDDFrGEzYzlelDeXmK7mzfmo
> =4kga

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 13 Aug 2010 11:55:58 -0700

d/
-- 

   Dave Crocker

---

From: Sam Hartman <[email-masked]>
Date: Fri, 13 Aug 2010 18:49:15 -0400

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

    Dave> The charter really needs to state fairly clearly what the
    Dave> boundaries of change are, within the charter.  It needs to
    Dave> state it forcefully enough to be useful when someone starts
    Dave> distracting the working group with calls for changes that
    Dave> really go beyond what the working group intends.  This is a
    Dave> question of clarity about what the working group intends and
    Dave> strong enough language in the charter to be used as an
    Dave> enforcement club.  I'd say that there is already plenty of
    Dave> demonstrated need for such a paragraph.

Dave, I agree with the above paragraph.

That's why I want the fourth paragraph to go away.  The fourth paragraph
states a constraint that I believe is too weak.  Other text in the
charter states the constraint that I believe is correct.

So, I am in completely agreement that we need to state the constraints,
I just want to state the right one.

---

From: Dave CROCKER <[email-masked]>
Date: Sat, 14 Aug 2010 08:46:25 -0700

On 8/13/2010 12:19 PM, Leif Johansson wrote:
> So given that the

Taken to its logical extreme, this means that there is no need for a charter. 
Everything is subject to working group consensus.

The charter is a combination marketing tool and stick.  By marketing, I mean 
telling other folks what is going to be done, so that they can decide whether to 
authorize it (iesg) or participate in it (contributors.)

By stick I mean that it can be used to expedite working group management, aiding 
chairs in restricting discussion. (More positively, this means aiding chairs in 
keeping the discussion constructively focused.)

Consider the BOF that just took place.  Consider the range of comments from the 
microphone.  In particular, consider how /many/ of those comments suggested 
replacing or adding one or another technology, rather than suggesting evaluation 
and enhancement of the proposal that motivated the BOF.

It's easy to believe that that will happen at a BOF but not aftering chartering, 
but some working groups are not so lucky.  I prefer charters that anticipate the 
problem continuing, especially when there's some basis for the fear in a 
particular case.  I think this is one of those.

Imagine those kinds of "contributions" continuing throughout the life of the 
working group and the working group's having to do a full discussion and 
consensus call each time.  This does sometimes happen in working groups.  It is 
extremely inefficient and often winds up being a denial of service attack that 
ultimately discourages serious participants.

The alternative is to permit the chairs to immediately declare a contribution 
out of scope.  But this requires that the chairs be able to point to something 
that declares the scope well enough to withstand a process challenge.

That's why I'm pressing for this extra language in the charter.

 > and a recharter". Isn't that last bit _always_ redundant in the IETF?

Excellent question.  The difference is between stating what forms the starting 
point versus stating the rules for changing it.  What kinds of changes are 
permitted and what kind are not?

 > charter states the constraint that I believe is correct.

Oh.

> specifically SAML, EAP (RFC 3748) and AAA (RADIUS, Diameter).

and

> The working group will develop a solution ...  by combining SAML, EAP (RFC

On reflection, it does seem unlikely that using any other technology components 
would formally be within scope.  Very crisp working group management ought to be 
able to use these statements to keep the working group in focus.

Over time, I've come to appreciate the problem of demanding too much from IETF 
working group chairs.  They need as much help as they can be given, for working 
groups covering topics that are "interesting".  (Interesting means either or 
both of technically difficult or participant difficult.)

I believe this topic qualifies as both and that even if the fourth paragraph is 
redundant, it will be safer to give the chairs the extra help.

I also think that "requires rechartering" is the single most powerful statement 
that can be made in a charter.  It's the highest possible barrier.

d/
-- 

   Dave Crocker

---

From: Sam Hartman <[email-masked]>
Date: Mon, 16 Aug 2010 08:45:34 -0400

>>>>> "Dave" == Dave CROCKER <[email-masked]> writes:
    Dave> That's why I'm pressing for this extra language in the
    Dave> charter.

I wonder if my disagreement isn't simply about the existing language.

I read the current fourth paragraph as encouraging people to bring
forward proposals to change fundamental technology choices; the bar they
need to meet is consensus to recharter.  So, I agree with your overall
goal, I just question whether the specific text actually accomplishes
that goal.

One reason I read things this way is that we actually are encouraging
people to come forward with sufficiently interesting proposals for
additional work--for example a way to integrate into some non-GSS
application.  The bar for those changes is also a recharter, but it's
something that we expect we might want to do.

If we want to say that we do not anticipate a need to change the
fundamental technology choices, let's just say that.  Perhaps something
like "As discussed below, the WG is open to adding new ways to interface
to applications through the recharter process. The WG does not
anticipate revisiting the technology choices in the previous paragraph."

My goal is to emphasize theconstraint rather than the procedure for
getting around the constraint.

Could something like that work for folks?

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 16 Aug 2010 23:03:57 +0900

The current charter text gives two reasons for rechartering:

o Changing the technology choices, i.e, SAML, EAP and AAA.

o Adding a new application interface (e.g., for non-GSS applications)
under the above technology choices.

It does not seem logical (to me) to put the same level of bar for
these two types of modifications while we say that in the charter that
the latter type of modifications are in the scope: "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 ..."

I think one reason for putting the same level of bar for the two types
of modifications is based on whether a solution has been presented or
discussed in the BoF.  For example, other technology choices and
non-GSS application interfaces were not presented in the BoF.  This
would be a fair reasoning, but on the other hand I am wondering why a
WG consensus is not sufficient for the latter type of modifications.

Best Regards,
Yoshihiro Ohba

(2010/08/16 21:45), Sam Hartman wrote:
>>>>>> "Dave" == Dave CROCKER<[email-masked]>  writes:

---

From: Sam Hartman <[email-masked]>
Date: Mon, 16 Aug 2010 10:16:29 -0400

>>>>> "Yoshihiro" == Yoshihiro Ohba <[email-masked]> writes:

    Yoshihiro> The current charter text gives two reasons for
    Yoshihiro> rechartering: o Changing the technology choices, i.e,
    Yoshihiro> SAML, EAP and AAA.

    Yoshihiro> o Adding a new application interface (e.g., for non-GSS
    Yoshihiro> applications) under the above technology choices.

    Yoshihiro> It does not seem logical (to me) to put the same level of
    Yoshihiro> bar for these two types of modifications while we say
    Yoshihiro> that in the charter that the latter type of modifications
    Yoshihiro> are in the scope: "Initially the working group will focus
    Yoshihiro> on using GSS-API (RFC2743) as a mechanism for integrating
    Yoshihiro> the developed solution for federated identity into
    Yoshihiro> application protocols but other technologies for
    Yoshihiro> application interface are in scope of the working group
    Yoshihiro> ..."

I agree with you.
I do think  that  the bar is different.
Getting a new application interface added should look like a mini-bof.
Someone should present  a proposal that is well researched and well
defined enough for us to evaluate it.
Then we discuss whether it is a good idea and if we think so, propose
modifying our charter.
The reason we want a charter modification is to give the IESG an
opportunity to comment and if the new charter is accepted get the IESG
on-board with the new deliverable.
We also want to give the IETF as a whole a chance to comment.

At a process level, changing the fundamental technology choices would
also be a recharter.  However, I'd expect that to generally be a much
bigger up-hill battle.  The difference in the bar is that you're
probably going into the discussion of adding a new interface with
relatively open minds. You're probably going into the discussion of the
fundamental technology choice with a much higher probability that the
discussion (at least within the wg) will be closed down fairly quickly
and that there will be strong objections.

    Yoshihiro> I think one reason for putting the same level of bar for
    Yoshihiro> the two types of modifications is based on whether a
    Yoshihiro> solution has been presented or discussed in the BoF.  For
    Yoshihiro> example, other technology choices and non-GSS application
    Yoshihiro> interfaces were not presented in the BoF.  This would be
    Yoshihiro> a fair reasoning, but on the other hand I am wondering
    Yoshihiro> why a WG consensus is not sufficient for the latter type
    Yoshihiro> of modifications.

>From a management standpoint it's strongly desirable to have a recharter
 when the work of a WG significantly changes.  That gives the rest of
 the IETF the opportunity to get on board with the work plan.  It
 significantly raises the bar later for someone to claim that  work
should not have been done.

--Sam

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 16 Aug 2010 16:46:54 -0700

On 8/16/2010 5:45 AM, Sam Hartman wrote:
> forward proposals to change fundamental technology choices;

oh. that hadn't occurred to me.

> anticipate revisiting the technology choices in the previous paragraph."

I suggest something simpler and more direct:

    Any change in the choices for these three technical roles is out of scope 
for this charter.

d/
-- 

   Dave Crocker

---

From: Klaas Wierenga <[email-masked]>
Date: Tue, 17 Aug 2010 08:49:13 +0200

On 8/17/10 1:46 AM, Dave CROCKER wrote:
> Any change in the choices for these three technical roles is out of
> scope for this charter.

This strong a statement was not made in the room during the BoF, but 
consensus is achieved on the mailing list. So please everyone speak up 
whether this is what we want to do.

Klaas

---

From: Leif Johansson <[email-masked]>
Date: Tue, 17 Aug 2010 08:55:06 +0200

> whether this is what we want to do.

I agree. We need more people chiming in on this.

	Cheers Leif

---

From: Eliot Lear <[email-masked]>
Date: Tue, 17 Aug 2010 09:41:12 +0200

Dave,

>    Any change in the choices for these three technical roles is out of

As I wrote earlier, I do not mind seeing alternative approaches
develop.  This having been said, I'll suggest that if an idea develops
sufficiently that it warrants attention, there are plenty of ways to
move forward.  And so, +1.

Eliot

---

From: Sam Hartman <[email-masked]>
Date: Tue, 17 Aug 2010 08:38:43 -0400

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

    Dave>    Any change in the choices for these three technical roles
    Dave> is out of scope for this charter.

Works for me.

---

From: Leif Johansson <[email-masked]>
Date: Tue, 17 Aug 2010 20:28:05 +0200

>     Dave> is out of scope for this charter.

I'd be happier with some more expressions of support (or at least
absense of dissent) but I plan to summarize the current state in
a v4 of the charter tomorrow.

	Cheers Leif

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 18 Aug 2010 07:36:35 +0900

+1

Yoshihiro Ohba

(2010/08/18 3:28), Leif Johansson wrote:
> iEYEARECAAYFAkxq1LUACgkQ8Jx8FtbMZnfCtQCgyIDUpHDOtYZHc0C0mVYGIok+
> Zh0AnizrOmNWWOpX3Pa9ay8XefY+hz2R
> =Gyqt

---

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

On Mon, Aug 16, 2010 at 04:46:54PM -0700, Dave CROCKER wrote:
>    Any change in the choices for these three technical roles is out
> of scope for this charter.

It isn't really possible to bind future charters in this one.  The WG
and IESG can do what they like in the future.

What I think we must do is list the technologies that will be the basis
for WG work items.

We should also note that work items based on other technologies will
require re-chartering, and we should state the requirements that we
think those technologies must meet.  Even though we can't bind the WG
and the IESG to those requirements, stating them will be useful.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Thu, 19 Aug 2010 13:04:33 -0400

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    >> of scope for this charter.

    Nicolas> It isn't really possible to bind future charters in this
    Nicolas> one.  The WG and IESG can do what they like in the future.

True.  Note that the quoted text doesn't speak about future charters.

    Nicolas> What I think we must do is list the technologies that will
    Nicolas> be the basis for WG work items.

    Nicolas> We should also note that work items based on other
    Nicolas> technologies will require re-chartering, and we should
    Nicolas> state the requirements that we think those technologies
    Nicolas> must meet.  Even though we can't bind the WG and the IESG
    Nicolas> to those requirements, stating them will be useful.

I think we do all that.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 19 Aug 2010 12:15:24 -0500

>     Nicolas> to those requirements, stating them will be useful.

Do we?  I looked at the draft charter posted at start of this thread and
saw nothing about mutual authentication nor channel binding, for
example.  I also saw nothing about the GSS-API mechanism being usable in
Internet protocols that support the use of GSS-API mechanisms, or in
some subset, therefore I cannot derive a requirement for support of
host-based service names, mutual authentication, channel binding, nor
per-message tokens from the charter text.

It's probably not fatal if the charter fails to say any of those things.
But I think it'd be very useful if it did.

Nico
--

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 19 Aug 2010 10:19:21 -0700

> per-message tokens from the charter text.

The etiquette, at this stage of this process, is to offer specific draft text 
changes.

It moves discussion from concept to concrete.  That usually makes it far easier 
to resolve the concerns (or dismiss them.)

d/
-- 

   Dave Crocker

---

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

On Thu, Aug 19, 2010 at 10:19:21AM -0700, Dave CROCKER wrote:
> The etiquette, at this stage of this process, is to offer specific
> draft text changes.

Perhaps, but first I wanted to make sure I wasn't missing something.
It'd be silly to waste your time on reviewing proposed text if the
proposal was redundant as a result of my having missed some detail.

Once I'm sure that the proposed charter fails to address this one issue
even indirectly, then I'll propose text.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Thu, 19 Aug 2010 13:50:43 -0400

Nicolas> On Thu, Aug 19, 2010 at 10:19:21AM -0700, Dave CROCKER wrote:
    >> The etiquette, at this stage of this process, is to offer
    >> specific draft text changes.

    Nicolas> Perhaps, but first I wanted to make sure I wasn't missing
    Nicolas> something.  It'd be silly to waste your time on reviewing
    Nicolas> proposed text if the proposal was redundant as a result of
    Nicolas> my having missed some detail.

Ah.
I was thinking of much higher level things  when I thought of
requirements.
You're right that the issues you mention are not in the current charter.

At least with respect to the GSS mechanism, while I'm happy to have
those requirements in the charter, I think we have enough GSS people in
the group who care about those issues that it won't be a problem.
However I do think it would be great to say that interfaces to integrate
into applications need to support mutual authentication and channel
binding.  Could you draft text for that?

--Sam

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 19 Aug 2010 10:57:40 -0700

On 8/19/2010 10:50 AM, Sam Hartman wrote:
>  I think we have enough GSS people in

My view:

A charter that specifies the use of very specific technologies and has barriers 
against alternatives needs to be complete in the list of technologies.  It must 
not rely on assumptions or the composition of the working group.

d/
-- 

   Dave Crocker

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 19 Aug 2010 13:08:42 -0500

> You're right that the issues you mention are not in the current charter.

I see two places where these are implied:

   "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

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

The implication is a bit weak for my taste.  The fact that these
constraints derive from existing Internet protocols is extremely useful,
as they are much harder to change than it is to change a WG's charter.

Stating these constraints explicitly should be also be useful.  They
will help folks interested in bringing new work items to this WG
(they'll know a priori what features are required).  And they will help
the WG (and the IESG and the IETF) analyze whether this WG would be a
suitable home to such work items.

> binding.  Could you draft text for that?

Here's my proposed text, to be slotted into the constraints section,
preferably right after the first paragraph of that section:

   Note that in order to be usable in all current Internet protocols,
   GSS-API mechanism must provide the following features: mutual
   authentication, key confirmation, host-based service naming,
   per-message tokens ("security layers") and channel binding.  Support
   for GSS_Pseudo_random() is desirable, and generally feasible whenever
   per-message tokens are supported.  As a result, all of those features
   are required for GSS-API mechanisms produced by this WG.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 19 Aug 2010 13:17:11 -0500

On Thu, Aug 19, 2010 at 10:57:40AM -0700, Dave CROCKER wrote:
> A charter that specifies the use of very specific technologies and
> has barriers against alternatives needs to be complete in the list
> of technologies.  It must not rely on assumptions or the composition
> of the working group.

But Sam asked for text nonetheless.  I just supplied it.

But also, it's better to state "natural" requirements and constraints
than it is to merely list some technologies.  A GSS-API mechanism based
on required technologies might nonetheless fail to meet such natural
requirements.

The really useful thing here is that the constraints in question are
external (which is what I meant by "natural"): they derive from the
details of Internet SASL and GSS-API applications.  Such constraints are
much harder to argue with than mere personal preferences.  They also
provide much more information to newcomers.

Want to know why host-based service names are required?  Just look at
the GSS-API applications we want to be able to use your GSS-API
mechanism in.  Don't care to support such applications?  Then your
mechanism is by definition of no interest to us (and here "us" likely
evaluates to the IETF, not just the WG).

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Thu, 19 Aug 2010 14:26:21 -0400

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> Here's my proposed text, to be slotted into the constraints section,
    Nicolas> preferably right after the first paragraph of that section:

    Nicolas> Note that in order to be usable in all current Internet protocols,
    Nicolas> GSS-API mechanism must provide the following features:
    Nicolas> mutual
s/GSS-API/GSS-API or SASL
    Nicolas> authentication, key confirmation, host-based service naming,
    Nicolas> per-message tokens ("security layers") and channel binding.  Support
    Nicolas> for GSS_Pseudo_random() is desirable, and generally feasible whenever
    Nicolas> per-message tokens are supported.  As a result, all of those features
    Nicolas> are required for GSS-API mechanisms produced by this WG.
I'd like to add:
Other application integration strategies are very likely to mirror these
    Nicolas> constraints. In particular, mutual authentication and
    Nicolas> support for channel binding are likely to be important for
    Nicolas> defense against phishing attacks.

--Sam

    Nicolas> Nico
    Nicolas> --

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 19 Aug 2010 13:32:32 -0500

On Thu, Aug 19, 2010 at 02:26:21PM -0400, Sam Hartman wrote:
> Other application integration strategies are very likely to mirror
> these constraints. In particular, mutual authentication and support
> for channel binding are likely to be important for defense against
> phishing attacks.

Agreed.  Also, I think it's worth mentioning SASL/GS2 in the same
paragraph.  New text:

   Note that in order to be usable in all current Internet protocols,
   GSS-API mechanism must provide the following features: mutual
   authentication, key confirmation, host-based service naming,
   per-message tokens ("security layers") and channel binding.  Support
   for GSS_Pseudo_random() is desirable, and generally feasible whenever
   per-message tokens are supported.  As a result, all of those features
   are required for GSS-API mechanisms produced by this WG.  Note also
   that some of these requirements derive from SASL applications, which
   can use GSS-API mechanisms through GS2.  Other application
   integration strategies are very likely to mirror these constraints.
   In particular, host-based service naming, mutual authentication and
   support for channel binding are likely to be important for defense
   against phishing attacks.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Thu, 19 Aug 2010 14:35:45 -0400

This text looks good to me.

---

From: Leif Johansson <[email-masked]>
Date: Fri, 20 Aug 2010 15:51:33 +0200

>    against phishing attacks.

I'm probably missing something, but why does this not belong in a
problem-statement draft instead of in the charter?

	Cheers Leif

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 20 Aug 2010 11:29:38 -0500

> problem-statement draft instead of in the charter?

This is about constraints on the output of the WG.  Therefore it seems
to me that it belongs in the constraints section.  The problem statement
needs to (and IIRC does) mention the GSS-API connection, but why burden
the reader of the problem statement with a lengthy paragraph regarding
constraints?

Nico
--