Subject: [abfab] Core documents: where we are

From: Sam Hartman <[email-masked]>
Date: Fri, 23 Sep 2011 10:05:54 -0400

Hi.  I'd like to give my take on the core documents and where I think we
are in the hopes of soliciting feedback.

Architecture:
We have an initial version out. We've received a lot of feedback from
Jim and some from Alexey that we need to integrate.
We need to write a security considerations section and we need to write
sections on proxy behavior.

In my opinion, it's more important to focus on the technical specs at
this point than the architecture document. We definitely should have
some update by IETF 82 to make forward prograss, but I don't think it is
critical that it be complete. In effect I'm arguing that the initial
order of our milestones is wrong and that we want to conclude core specs
before architecture.

* gss-eap: I think this is complete enough that we can get significant
  review. There are some open ends:

* Actually including an OID from the OID registry

* Including the error codes that you might want to return

* Including a sample token

* Some figures might be nice. If people write figures I'll include
  them:-)

But I believe the protocol is well specified enough to have an informed
discussion.

* aaa-saml.

we've had several discussions of this. We need to specify more semantics
to address issues Jim and I have raised..
We have a description of the attribute.
We need to turn that into descriptions of the semantics of the
attribute.  In effect it needs to be more of a SAML binding.
The fact that this is not written down is hurting us and this doc should
be a real priority.

* gss-eap-naming:
This document needs and will get a major update.
It needs to reflect changes in naming extensions. When this document was
written it was as much an argument that naming extensions was broken as
it was a description of how to do things in GSS-EAP.
Never the less we've gotten significant feedback from Jim and I think
we'll be in very good shape for review once this feedback is integrated
into the document.

--Sam

---

From: Leif Johansson <[email-masked]>
Date: Fri, 23 Sep 2011 16:15:04 +0200

<snip>

> this point than the architecture document. We definitely should have

This was already discussed in Quebec and the WG concluded that were
fine with Elliot putting the architecture document on the back-burner
for a little while while the core technical spec was moved ahead.

I don't think we need to re-iterate that decision.

> order of our milestones is wrong and that we want to conclude core specs

Yes. cf above.

	Cheers Leif

---

From: Leif Johansson <[email-masked]>
Date: Fri, 23 Sep 2011 16:21:03 +0200

<snip>

When do you think you and Josh will have an update on 02 out?

> The fact that this is not written down is hurting us and this doc should

The charter has us coordinating this with OASIS since a SAML binding
should probably be published there but we don't actually have a stuckee
for this job. My hope was to get Scott to do it.... hint hint, nudge
nudge...

> This document needs and will get a major update.

When do you think we can expect an updated version?

	Cheers Leif

---

From: Sam Hartman <[email-masked]>
Date: Fri, 23 Sep 2011 11:06:48 -0400

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

    >> * gss-eap: I think this is complete enough that we can get
    >> significant review. There are some open ends:

    Leif> <snip>

    Leif> When do you think you and Josh will have an update on 02 out?
At some point in October , probably gss-eap right at the cutoff.
I don't think those updates significantly affect the ability of people
to review it.
The updates to  aaa-saml and gss-eap-naming are more important, although
it's very unlikely we can get started on that before October 12.

    >> 
    >> * aaa-saml.
    >> 
    >> we've had several discussions of this. We need to specify more
    >> semantics to address issues Jim and I have raised..  We have a
    >> description of the attribute.  We need to turn that into
    >> descriptions of the semantics of the attribute.  In effect it
    >> needs to be more of a SAML binding.  The fact that this is not
    >> written down is hurting us and this doc should be a real
    >> priority.
    >> 

The charter has us coordinating this with OASIS since a SAML binding
    Leif> should probably be published there but we don't actually have
    Leif> a stuckee for this job. My hope was to get Scott to do
    Leif> it.... hint hint, nudge nudge...

Hannes and several participants have proposed that  be folded into
aa-saml.
I'm not aware of anyone advocating for OASIS documents at this point.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 23 Sep 2011 11:10:52 -0400

>>>>> "Sam" == Sam Hartman <[email-masked]> writes:

    Leif> <snip>

    Leif> When do you think you and Josh will have an update on 02 out?
    Sam> At some point in October , probably gss-eap right at the
    Sam> cutoff.  I don't think those updates significantly affect the
    Sam> ability of people to review it.  The updates to aaa-saml and
    Sam> gss-eap-naming are more important, although it's very unlikely
    Sam> we can get started on that before October 12.

    Sam> Hannes and several participants have proposed that be folded
    Sam> into aa-saml.  I'm not aware of anyone advocating for OASIS
    Sam> documents at this point.
    Sam> _______________________________________________ abfab mailing
    Sam> list [email-masked] https://www.ietf.org/mailman/listinfo/abfab

Ah, messages in another thread suggest there are still people who want
to see this done in OASIS.  There are others who have asked it be done
here.
I guess that's an open issue.

---

From: Nico Williams <[email-masked]>
Date: Fri, 23 Sep 2011 10:13:00 -0500

My advice would be to find a way to do all the work here, and not
split any of it to OASIS.

---

From: "Leif Johansson" <[email-masked]>
Date: Fri, 23 Sep 2011 17:47:11 +0200

It would be convenient for us but I'worried we may miss important feedback. Perhaps Thomas Hardjono can advise us ...

23 sep 2011 kl. 17:13 skrev "Nico Williams" <[email-masked]>:

> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab

---

From: "Cantor, Scott" <[email-masked]>
Date: Fri, 23 Sep 2011 19:09:51 +0000

On 9/23/11 11:47 AM, "Leif Johansson" <[email-masked]> wrote:

>
>It would be convenient for us but I'worried we may miss important
>feedback. Perhaps Thomas Hardjono can advise us ...

I can more easily offer a promise of review than I can volunteer to author
and shepherd yet another spec at this point.

And doing an binding at OASIS is only of interest to me if it's
sufficiently generic. I'm not sure yet whether this work is going to be
sensibly of use to carry arbitrary SAML protocols. It still feels use case
(or profile-) specific to me.

-- Scott

---

From: Sam Hartman <[email-masked]>
Date: Fri, 23 Sep 2011 15:44:17 -0400

>>>>> "Cantor," == Cantor, Scott <[email-masked]> writes:

    Cantor,> And doing an binding at OASIS is only of interest to me if
    Cantor,> it's sufficiently generic. I'm not sure yet whether this
    Cantor,> work is going to be sensibly of use to carry arbitrary SAML
    Cantor,> protocols. It still feels use case (or profile-) specific
    Cantor,> to me.

I agree. I think we're explicitly making it profile specific.

---

From: Leif Johansson <[email-masked]>
Date: Fri, 23 Sep 2011 21:59:45 +0200

> I agree. I think we're explicitly making it profile specific.

OK so our charter doesn't say we absolutely have to do a binding in
OASIS SSTC as long as we coordinate with that group.

Scott and Thomas - do you think we can ask the SSTC to review?

	Cheers Leif

---

From: Josh Howlett <[email-masked]>
Date: Fri, 23 Sep 2011 21:06:59 +0000

>I agree. I think we're explicitly making it profile specific.

I think we ultimately need a profile specific solution for Abfab's
purposes, and a generic binding that can be applied to other domains. The
problem is that its all being shoehorned into single document. Here's a
proposal:

1. RADIUS SAML attribute (Abfab): specifies encapsulation of SAML messages
within RADIUS messages, per 01.
2. RADIUS SAML binding (OASIS): generic application of (1) for the puspose
of a SAML binding
3. Abfab profile (Abfab): application of RADIUS SAML binding within Abfab
architecture (covers issues such as authentication and attribute request)

I had assumed that (3) would end up as part of the architecture document,
but that's now non-normative so perhaps we need a new document...

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 Oxford, Didcot, Oxfordshire. OX11 0SG

---

From: "Cantor, Scott" <[email-masked]>
Date: Fri, 23 Sep 2011 21:29:37 +0000

>Scott and Thomas - do you think we can ask the SSTC to review?

Yes, though there are all of about 6-8 voting members left, let alone
active ones.

-- Scott

---

From: "Cantor, Scott" <[email-masked]>
Date: Fri, 23 Sep 2011 21:36:06 +0000

>but that's now non-normative so perhaps we need a new document...

Well, you definitely need (3) in some normative document, and it's really
the most important piece in SAML terms. I can see having (1) on its own
for reuse. (2) doesn't necessarily have to be done on its own right out of
the gate; it could be combined with (3) as part of the profile, and if
there's interest in reuse, then a new binding could be done to factor it
out.

At an implementation level, this isn't the kind of binding you really get
leverage from anyway. The HTTP and SOAP bindings are all playing in a
common framework and you implement them using obvious reusable widgets so
that you can plug them in. I don't really see that here because the
transport is very specialized (at least to those of us not steeped in this
stuff). Unless you have in mind that other bindings over the same
transport are on the horizon.

-- Scott

---

From: Sam Hartman <[email-masked]>
Date: Fri, 23 Sep 2011 18:47:11 -0400

>>>>> "Josh" == Josh Howlett <[email-masked]> writes:

    >> Cantor,> And doing an binding at OASIS is only of interest to me
    >> if Cantor,> it's sufficiently generic. I'm not sure yet whether
    >> this Cantor,> work is going to be sensibly of use to carry
    >> arbitrary SAML Cantor,> protocols. It still feels use case (or
    >> profile-) specific Cantor,> to me.
    >> 

    Josh> I think we ultimately need a profile specific solution for
    Josh> Abfab's purposes, and a generic binding that can be applied to
    Josh> other domains. The problem is that its all being shoehorned
    Josh> into single document. Here's a proposal:

    Josh> 1. RADIUS SAML attribute (Abfab): specifies encapsulation of
    Josh> SAML messages within RADIUS messages, per 01.  2. 

I'm very uncomfortable with a generic binding. I think we have a lot of
good reasons why the RP needs to know the semantics here.
So, I think we need normative references from our specs to the
semantics, and the attribute (or a sub-attribute) needs to be scoped to
those semantics/profile.

So, I'm not very happy with item 1.

    Josh> RADIUS SAML
    Josh> binding (OASIS): generic application of (1) for the puspose of
    Josh> a SAML binding

What do we get out of doing this work in OASIS other than OASIS review?
Can you contrast with doing it here with OASIS review?

Here are my concerns about OASIS

1) Can we come to consensus on something both groups can accept? We seem
to believe that the semantics are important. OASIS seems to leave that
to profiles.

2) It introduces publication complexity.

3)  Do the right people participate?

4) Bringing SSTC up to speed.

5) Strong experience that changing the venue of a work leads to
multi-year delays. That's within the IETF from one wg to another.

    Josh>  3. Abfab profile (Abfab): application of RADIUS
    Josh> SAML binding within Abfab architecture (covers issues such as
    Josh> authentication and attribute request)

    Josh> I had assumed that (3) would end up as part of the
    Josh> architecture document, but that's now non-normative so perhaps
    Josh> we need a new document...

Or fold it all into aaa-saml.

---

From: "Klaas Wierenga (kwiereng)" <[email-masked]>
Date: Sun, 25 Sep 2011 11:06:25 +0200

Hi,

This all seems sensible. So how about we proceed inside abfab, get review of (3) from those who are involved in OASIS to make sure we don't screw up, and revisit the issue if/when we believe the binding might get traction beyond this specific case?

Klaas

--
Klaas Wierenga
Consulting Engineer - Office of the CTO
Cisco Systems 

-----Original Message-----
From: [email-masked] on behalf of Cantor, Scott
Sent: Fri 9/23/2011 11:36 PM
To: Josh Howlett; Sam Hartman
Cc: [email-masked]
Subject: Re: [abfab] Core documents: where we are

-- Scott