Subject: [abfab] [Sam Hartman] comments on draft-ietf-abfab-arch

From: Sam Hartman <[email-masked]>
Date: Wed, 04 Sep 2013 09:04:17 -0400

Sent from wrong address.

Subject: comments on draft-ietf-abfab-arch
From: Sam Hartman <[email-masked]>
To: [email-masked]
Date: Tue, 03 Sep 2013 18:04:22 -0400

My apologies for not getting these out in last call.
One of these (the re-authentication section comment) is serious enough
that I believe it needs to be resolved prior to sending the document on.

Section 1.1.1

old: Typically when considering channel binding

new:

Typicially when considering both EAP and GSS-API channel binding

Later in the white board example
channel binding should be GSS-API channel binding

Section 2.3.3

This is unlikely to survive IETF last call unchallenged.

Section 3.4

old: shared private key
new: shared session key

Section 2.2.2 refers to sectian 6.1 for a description of GSS-API channel
binding; that seems wrong

---

From: Leif Johansson <[email-masked]>
Date: Wed, 04 Sep 2013 15:09:38 +0200

Folks - Can I get some quick feedback on this!

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 4 Sep 2013 21:50:11 -0700

It will probably be Sunday before I get to this.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Leif Johansson
> Sent: Wednesday, September 04, 2013 6:10 AM
> To: [email-masked]
> Subject: Re: [abfab] [Sam Hartman] comments on draft-ietf-abfab-arch
> 
> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab

---

From: "Jim Schaad" <[email-masked]>
Date: Sun, 22 Sep 2013 21:21:08 -0700

My apologies for not getting these out in last call.
One of these (the re-authentication section comment) is serious enough that
I believe it needs to be resolved prior to sending the document on.

Section 1.1.1

new:

[JLS] done

[JLS]  I don't understand this.   The two sentences which talk about the
whiteboard do not have the phrase channel binding in them.  The next
sentence would seem to apply to either GSS-API or EAP channel binding.
Which sentence did you think should be changed?

Section 2.3.3

[JLS] Quite correct - this should say - please present your authentication
token

... 

          <t>
            There are circumstances where the server will want to have the
client re-authenticate itself.
            These include very long sessions, where the original
authentication is time limited or cases where in order to complete an
operation a different authentication is required.
            GSS-EAP does not have any mechanism for the server to initiate a
re-authentication as all authentication operation start from the client.
            If a protocol using GSS-EAP needs to support re-authentication
that is initiated by the server, then a request from the server to the
client for the re-authentication to start needs to be placed in the
protocol.
          </t>
          <t>
            Clients can re-use the existing secure connection established by
GSS-API to run the new authentication in by calling GSS_Init_sec_context.
            At this point a full re-authentication will be done.
          </t>

What do you think needs to be added to this?

Section 3.4

old: shared private key
new: shared session key

[JLS] - Fixed

[JLS] Section 6 has disappeared - so I am killing that portion of the
section.

> Of Sam Hartman
> Sent: Wednesday, September 04, 2013 6:04 AM
> To: [email-masked]
> Subject: [abfab] [Sam Hartman] comments on draft-ietf-abfab-arch
> 
> Sent from wrong address.
>

---

From: David Chadwick <[email-masked]>
Date: Mon, 23 Sep 2013 07:48:16 +0100

Apologies from me as well Sam, here are my comments on 
draft-ietf-abfab-arch-07.txt

Technical

Section 1.
i) Data Minimization and User Participation: "There is currently no 
direct client participation in this decision." (i.e. release of identity 
attributes). We should say at this juncture that this is a major 
deficiency in existing federated systems, since the user does not have 
full consent or control over which of his identity attributes are 
released. This should be fixed in Abfab

ii) Section 1.1.1
Authenticator should be defined before it is used.

iii) I dont buy into your whiteboard example of single entity 
authentication, because a hacked whiteboard could trick the user into 
opening the wrong file, which could be disasterous during an important 
business meeting. SO mutual authentication is needed here as well. If 
you want an example where mutual authentication is not important, its 
one where either the information being accessed is of very little value 
to the accessor so that it does not matter if it is erroneous 
information or not, or one where it does not matter who the accessor is 
i.e. its public information.

Editorials

Section 1
the Relying Party know specific -> the Relying Party to know specific

Section 1.1
the document uses either a the ABFAB term -> the document uses either 
the ABFAB term
The table should be labelled "Table 1. Terminology"

Section 1.4
a SAML Attribute Requests -> a SAML Attribute Request

Section 2.1.3
to validate theg identities -> to validate the identities
The trust mechanism must to ensure that -> The trust mechanism must 
ensure that
An RP can submit a request directly to a federation. -> An RP can submit 
a request directly to the correct federation.
information about given a IdP -> information about a given IdP

regards

David

---

From: Sam Hartman <[email-masked]>
Date: Mon, 23 Sep 2013 08:27:39 -0400

>>>>> "Jim" == Jim Schaad <[email-masked]> writes:

> Later in the white board example channel binding should be
> GSS-API channel binding

    Jim> [JLS] I don't understand this.  The two sentences which talk
    Jim> about the whiteboard do not have the phrase channel binding in
    Jim> them.  The next sentence would seem to apply to either GSS-API
    Jim> or EAP channel binding.  Which sentence did you think should be
    Jim> changed?

If channel binding is used without mutual authentication, it is
effectively . . .

I know thatt statement is true for GSS-API channel binding, and that's
certainly what the reasoning in the white-board example applies to.

I'll admit that I considered not making the comment because it seems to
sort of apply to EAP channel binding.

However, mutual authentication in EAP applies to peer confidence that
it's talking to the right EAP server.  Without that, I'm not sure how
EAP channel binding gives you confidence you're disclosing anything in
the context of a particular NAS.  It's more like it gives you confidence
that the NAS would like to be thought of in a particular way.  That
might be useful but doesn't seem much of a security claim.

So, I have confidence in the statement for  GSS-API channel binding, but
am not at all sure it's true for EAP channel binding.

Your text for re-authentication seems good to me.

I do have one note about your response to Mark on secure lookups in DNS.
Previously the text simply said the lookup needed to be secure.  Your
replacement text to address Mark's concerns specifically introduces
discussion of DNSsec.
I'm wondering whether that's proscriptive.
I guess it's fine, because if you're actually using the DNS protocol
that and tsig are the only ways to secure the lookup.
So, I'm OK with the proposed text, but I want to call out that we've
refined the semantics somewhat.

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Mon, 23 Sep 2013 08:33:36 -0400

>>>>> "David" == David Chadwick <[email-masked]> writes:

    David> Section 1.  i) Data Minimization and User Participation:
    David> "There is currently no direct client participation in this
    David> decision." (i.e. release of identity attributes). We should
    David> say at this juncture that this is a major deficiency in
    David> existing federated systems, since the user does not have full
    David> consent or control over which of his identity attributes are
    David> released. This should be fixed in Abfab

I do not support this change.

There are some cases where this is a major deficiency, but it's not
entirely clear whether fixing this at the ABFAB layer is the right
approach.

I'd argue that trying to fix the concent problem in a general manner at
the federation layer may have done more harm over the years than the
privacy problem that is trying to be addressed.

    David> iii) I dont buy into your whiteboard example of single entity
    David> authentication, because a hacked whiteboard could trick the
    David> user into opening the wrong file, which could be disasterous
    David> during an important business meeting. SO mutual
    David> authentication is needed here as well. If you want an example
    David> where mutual authentication is not important, its one where
    David> either the information being accessed is of very little value
    David> to the accessor so that it does not matter if it is erroneous
    David> information or not, or one where it does not matter who the
    David> accessor is i.e. its public information.

Most of the tools I'm familiar with for screen sharing etc would not
allow the white board to pick the presentation/file.
I'd support adding a comment that you don't want to run UI on the white
board, but no I think I completely disagree with your proposed
constraints on when this is useful.

--Sam

---

From: Leif Johansson <[email-masked]>
Date: Mon, 23 Sep 2013 16:05:16 +0200

> privacy problem that is trying to be addressed.
With my chair-switch secured in the OFF position: I agree with Sam
100% here.

---

From: David Chadwick <[email-masked]>
Date: Mon, 23 Sep 2013 21:52:44 +0100

Hi Sam

> I do not support this change.

Which change do you not support
a) saying that this is a major deficiency in existing federated systems
b) saying that Abfab should fix this
c) both

> entirely clear whether fixing this at the ABFAB layer is the right

So it appears that you support a) but not b). So can you simply add a).

> privacy problem that is trying to be addressed.

Actually in my previous research we fixed this in a layer above the 
federation layer, which we called the attribute aggregation layer. So I 
agree that it is best to not fix it in the federation layer.

> allow the white board to pick the presentation/file.

Meaning that the user sends an already chosen file to the whiteboard?
In which case I agree with you.

> constraints on when this is useful.

I would be interested to learn of another generic type of use case where 
you think that mutual authn is not needed

regards

David

---

From: Sam Hartman <[email-masked]>
Date: Mon, 23 Sep 2013 23:12:16 -0400

>>>>> "David" == David Chadwick <[email-masked]> writes:
    David> Hi Sam
    >> I do not support this change.

    David> Which change do you not support a) saying that this is a
    David> major deficiency in existing federated systems b) saying that
    David> Abfab should fix this c) both

I do not support either change.
I'd be comfortable adding a statement that the ABFAB architecture does
not provide a specific way for the user to inform the IDP about the
user's requirements for attribute releases.
Whether that's a major deficiency depends on what you're doing.
I agree there are cases where it is.

    >> 
    >> I'd argue that trying to fix the concent problem in a general
    >> manner at the federation layer may have done more harm over the
    >> years than the privacy problem that is trying to be addressed.

    David> Actually in my previous research we fixed this in a layer
    David> above the federation layer, which we called the attribute
    David> aggregation layer. So I agree that it is best to not fix it
    David> in the federation layer.

    >> 
    >> Most of the tools I'm familiar with for screen sharing etc would
    >> not allow the white board to pick the presentation/file.

    David> Meaning that the user sends an already chosen file to the
    David> whiteboard?  In which case I agree with you.

Exactly.
So, let's make it clear that it's critical that the user's software not
trust input from the white board without mutual authentication.

--Sam

---

From: Rhys Smith <[email-masked]>
Date: Tue, 24 Sep 2013 14:59:37 +0000

> I agree there are cases where it is.

+1.

Deficiency is in the eye of the beholder and their use case at that moment in time. In many cases it happens to be a major problem, but it's not a fundamental deficiency.

Calling out that ABFAB doesn't provide a means for this - and making no judgement on that fact - seems like a good way to go to me.

Rhys.
--
Dr Rhys Smith
Identity, Access, and Middleware Specialist
Cardiff University & Janet - the UK's research and education network

email: [email-masked] / [email-masked]
GPG: 0xDE2F024C

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 27 Sep 2013 09:39:44 -0700

> From: David Chadwick [mailto:[email-masked]]
> Sent: Sunday, September 22, 2013 11:48 PM
> To: Jim Schaad
> Cc: 'Sam Hartman'; [email-masked]
> Apologies from me as well Sam, here are my comments on draft-ietf-abfab-
> arch-07.txt
> 
> Technical
> 
> Section 1.
> i) Data Minimization and User Participation: "There is currently no direct
client
> participation in this decision." (i.e. release of identity attributes). We
should
> say at this juncture that this is a major deficiency in existing federated
> systems, since the user does not have full consent or control over which
of his
> identity attributes are released. This should be fixed in Abfab

Based on the current set of abilities, there is no real way to fix this in
ABFAB itself.  I have thought of a proposed way to deal with this, but am
unsure where it would be bested addressed or even what the solution to the
problem would include.

If I was solving this today, I would define a couple of experimental items
in the TEAP protocol to allow for this to be done, however given that this
would definitely be experimental and the fact that the EMU group is trying
to go away it is not clear that this would be the group to do it.  I don't
think that ABFAB is really the place to do it either.  I think that there
needs to be some clear discussions about how this should be attacked as a
problem before we even think about it.  In some instances it is not clear
that that is any solution to the problem, such as when a SAML request goes
from the server to the IDP after the EAP authentication has been completed.
The only thing that could be possible in this case is for a profile to be
agreed on by the client and the IDP at the authentication time and for the
IDP to enforce it at a later time.

Given how unclear a solution would be for this I don't see any reason to
hold this document up over the fact that the ability for the user to fully
consent does not exist.  This has always been the case for RADIUS and
Diameter as well.

We can potentially strengthen the language that is present, although I don't
really see any need to do that either.  At present I do not plan to make any
changes to address this issue.

> Authenticator should be defined before it is used.

This has been fixed.

> iii) I dont buy into your whiteboard example of single entity
authentication,
> because a hacked whiteboard could trick the user into opening the wrong
file,
> which could be disasterous during an important business meeting. SO mutual
> authentication is needed here as well. If you want an example where mutual
> authentication is not important, its one where either the information
being
> accessed is of very little value to the accessor so that it does not
matter if it is
> erroneous information or not, or one where it does not matter who the
> accessor is i.e. its public information.

I don't see how having mutual authentication is going to solve anything in
the case of a hacked whiteboard getting the user to display the wrong file
or stealing credentials from the user in the case that it the initiator.
There would be no issue of the file server releasing the file to the
whiteboard if authorized by the user in all cases.  The only question would
be if the file server decided based on the name of the whiteboard that it
should not be released, but it would be the user that is authenticated in
this case and not the whiteboard so there would not be mutual authentication
between the file server and the whiteboard in any case.

I will send to the list updated text on this.  After a brief exchange with
Sam I believe this has some errors in it that need to be clarified.

> the Relying Party know specific -> the Relying Party to know specific
Fixed

> 
> Section 1.1
> the document uses either a the ABFAB term -> the document uses either the
> ABFAB term The table should be labelled "Table 1. Terminology"
Fixed

> a SAML Attribute Requests -> a SAML Attribute Request
Fixed

> 
> Section 2.1.3
> to validate theg identities -> to validate the identities The trust
mechanism
> must to ensure that -> The trust mechanism must ensure that An RP can
> submit a request directly to a federation. -> An RP can submit a request
> directly to the correct federation.

Fixed

> > [JLS] Quite correct - this should say - please present your
> > authentication token
> >
> > ...
> >
> >            <t>
> >              There are circumstances where the server will want to
> > have the client re-authenticate itself.
> >              GSS-EAP does not have any mechanism for the server to
> > initiate a re-authentication as all authentication operation start from
the
> client.
> >              If a protocol using GSS-EAP needs to support
> > re-authentication that is initiated by the server, then a request from
> > the server to the client for the re-authentication to start needs to
> > be placed in the protocol.
> >            </t>
> >            <t>
> >              Clients can re-use the existing secure connection
> > established by GSS-API to run the new authentication in by calling
> GSS_Init_sec_context.
> > Section 2.2.2 refers to sectian 6.1 for a description of GSS-API
> > channel binding; that seems wrong
> >
> >> From: [email-masked] [mailto:[email-masked]] On
> >> Behalf Of Sam Hartman

---

From: David Chadwick <[email-masked]>
Date: Sat, 28 Sep 2013 13:08:17 +0100

Hi Jim

thankyou for your long answer. Firstly I agree that the answer is not 
trivial, especially once you consider that an SP may require attributes 
from multiple IdPs/AAs. But leaving attribute aggregation aside, lets 
discuss conceptually what is needed in the simple single IDP case, 
before trying to figure out how to map this into the ABFAB protocols.

1. The SP is the only entity that knows which attributes are needed to 
access which of its services
2. The SP may not know this at the time of authn, as the user may not 
have chosen the service he wants to access at login time (assuming the 
SP has multiple services requiring different authz attributes).
3. If the user moves between the different services of the SP, using 
SSO, then different attributes may be needed at different times during 
the same authn session
4. DP legislation indicates that the SP should minimise the attributes 
it asks for, so a "grab them all" approach at authn time is not in the 
spirit of DP, and may be illegal in some juridictions
5. This indicates to me that the SP should be able to send its attribute 
requirements (or authz policy) to the IdP at arbitrary points in time 
during the user's session, and that the IDP should be able to send back 
attribute assertions that match the policy whenever requested to, 
providing that the user consents to this (and the IDP knows that the 
user has).

Is this challenge something the ABFAB group would like to take on, or 
should there be a BOF at a future IETF meeting to discuss this?

regards

David

---

From: "Klaas Wierenga (kwiereng)" <[email-masked]>
Date: Sun, 29 Sep 2013 07:12:49 +0000

Hi David,

> On 28 sep. 2013, at 14:08, "David Chadwick" <[email-masked]> wrote:
> 
> Hi Jim
> 
> thankyou for your long answer. Firstly I agree that the answer is not trivial, especially once you consider that an SP may require attributes from multiple IdPs/AAs. But leaving attribute aggregation aside, lets discuss conceptually what is needed in the simple single IDP case, before trying to figure out how to map this into the ABFAB protocols.
> 
> 1. The SP is the only entity that knows which attributes are needed to access which of its services
> 2. The SP may not know this at the time of authn, as the user may not have chosen the service he wants to access at login time (assuming the SP has multiple services requiring different authz attributes).
> 3. If the user moves between the different services of the SP, using SSO, then different attributes may be needed at different times during the same authn session
> 4. DP legislation indicates that the SP should minimise the attributes it asks for, so a "grab them all" approach at authn time is not in the spirit of DP, and may be illegal in some juridictions
> 5. This indicates to me that the SP should be able to send its attribute requirements (or authz policy) to the IdP at arbitrary points in time during the user's session, and that the IDP should be able to send back attribute assertions that match the policy whenever requested to, providing that the user consents to this (and the IDP knows that the user has).

I believe these are all fair statements and indicative of where we want federated identity systems to be eventually. At the same time, I think this is beyond the current scope of ABFAB. 

> Is this challenge something the ABFAB group would like to take on, or should there be a BOF at a future IETF meeting to discuss this?

With my chair hat on I'd say let's finish the current set of documents and not let the scope creep. Having said that, once we are done I'd welcome a discussion on how to address valid concerns about user consent and privacy, whether that would lead to concrete ideas and/or a WG (a rechartered ABFAB or new doesn't really matter to me).

Klaas

---

From: David Chadwick <[email-masked]>
Date: Sun, 29 Sep 2013 20:42:32 +0100

I would be interested in giving a presentation about this, but 
unfortunately I cannot attend the next IETF meeting as it clashes with 
Openstack in Honk Kong (where I am also giving a presentation on 
Federation). But the first meeting next year could be suitable

regards
David

On 29/09/2013 00:34, Jim Schaad wrote:
>   A BOF just to discuss the problem without some idea of a solution would
> probably not be very productive.
>
> I don't think that this problem is restricted to just ABFAB - I think that
> it is of interest to other groups and would therefore be reluctant to do
> more than a preliminary discussion in the ABFAB group to see if we even
> agree on the problem.
>
> I would suggest you ask the ABFAB chairs if there is room for some type of
> presentation if you are interested in doing a short presentation of what you
> see as the problem space and why it is not an easy solution.  I have added
> Trevor because I think that he would be interested in discussing this in the
> context of the Plasma work.
>
> Jim
>
>
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of
>> David Chadwick
>> Sent: Saturday, September 28, 2013 5:08 AM
>> To: Jim Schaad
>> Cc: [email-masked]; 'Sam Hartman'
> trivial,
>> especially once you consider that an SP may require attributes from
> multiple
>> IdPs/AAs. But leaving attribute aggregation aside, lets discuss
> conceptually
>> what is needed in the simple single IDP case, before trying to figure out
> how
>> to map this into the ABFAB protocols.
>>
> access
>> which of its services 2. The SP may not know this at the time of authn, as
> the
>> user may not have chosen the service he wants to access at login time
>> (assuming the SP has multiple services requiring different authz
> attributes).
>> 3. If the user moves between the different services of the SP, using SSO,
> then
>> different attributes may be needed at different times during the same
> authn
>> session 4. DP legislation indicates that the SP should minimise the
> attributes it
>> asks for, so a "grab them all" approach at authn time is not in the spirit
> of DP,
>> and may be illegal in some juridictions 5. This indicates to me that the
> SP
>> should be able to send its attribute requirements (or authz policy) to the
> IdP
>> at arbitrary points in time during the user's session, and that the IDP
> should be
>> able to send back attribute assertions that match the policy whenever
>> requested to, providing that the user consents to this (and the IDP knows
> that
>> the user has).
>>
>> there be a BOF at a future IETF meeting to discuss this?
>>
>> regards
>>
>> David
>>
>>>> draft-ietf-abfab- arch-07.txt
>>>>
>>>> Technical
>>>>
>>>> Section 1.
>>>> direct
>>>> say at this juncture that this is a major deficiency in existing
>>>> federated systems, since the user does not have full consent or
>>>> control over which
>>> of his
>>> Based on the current set of abilities, there is no real way to fix
>>> this in ABFAB itself.  I have thought of a proposed way to deal with
>>> this, but am unsure where it would be bested addressed or even what
>>> the solution to the problem would include.
>>>
>>> If I was solving this today, I would define a couple of experimental
>>> items in the TEAP protocol to allow for this to be done, however given
>>> that this would definitely be experimental and the fact that the EMU
>>> group is trying to go away it is not clear that this would be the
>>> group to do it.  I don't think that ABFAB is really the place to do it
>>> either.  I think that there needs to be some clear discussions about
>>> how this should be attacked as a problem before we even think about
>>> it.  In some instances it is not clear that that is any solution to
>>> the problem, such as when a SAML request goes from the server to the IDP
>> after the EAP authentication has been completed.
>>> The only thing that could be possible in this case is for a profile to
>>> be agreed on by the client and the IDP at the authentication time and
>>> for the IDP to enforce it at a later time.
>>>
>>> Given how unclear a solution would be for this I don't see any reason
>>> to hold this document up over the fact that the ability for the user
>>> to fully consent does not exist.  This has always been the case for
>>> RADIUS and Diameter as well.
>>>
>>> We can potentially strengthen the language that is present, although I
>>> don't really see any need to do that either.  At present I do not plan
>>> to make any changes to address this issue.
>>>
>>>>
>>>> ii) Section 1.1.1
>>>> which could be disasterous during an important business meeting. SO
>>>> mutual authentication is needed here as well. If you want an example
>>>> where mutual authentication is not important, its one where either
>>>> the information
>>> being
>>> I don't see how having mutual authentication is going to solve
>>> anything in the case of a hacked whiteboard getting the user to
>>> display the wrong file or stealing credentials from the user in the case
> that it
>> the initiator.
>>> whiteboard if authorized by the user in all cases.  The only question
>>> would be if the file server decided based on the name of the
>>> whiteboard that it should not be released, but it would be the user
>>> that is authenticated in this case and not the whiteboard so there
>>> would not be mutual authentication between the file server and the
>> whiteboard in any case.
>>>
>>> I will send to the list updated text on this.  After a brief exchange
>>> with Sam I believe this has some errors in it that need to be clarified.
>>>
>>>>
>>>>
>>>>
>>>> Editorials
>>>>
>>>> Section 1
>>>> the ABFAB term The table should be labelled "Table 1. Terminology"
>>> Fixed
>>>
>>>>
>>>> Section 1.4
>>>> submit a request directly to a federation. -> An RP can submit a
>>>> request directly to the correct federation.
>>>>> One of these (the re-authentication section comment) is serious
>>>>> enough that I believe it needs to be resolved prior to sending the
>> document on.
>>>>>
>>>>>
>>>>> Section 1.1.1
>>>>>
>>>>> authentication is time limited or cases where in order to complete
>>>>> an operation a different authentication is required.
>>>>> re-authentication that is initiated by the server, then a request
>>>>> from the server to the client for the re-authentication to start
>>>>> needs to be placed in the protocol.
>>>>>              </t>
>>>>>              <t>
>>>>> [JLS] Section 6 has disappeared - so I am killing that portion of
>>>>> the section.
>>>>>

---

From: Sam Hartman <[email-masked]>
Date: Mon, 30 Sep 2013 07:11:18 -0400

>>>>> "David" == David Chadwick <[email-masked]> writes:

    David> I would be interested in giving a presentation about this,
    David> but unfortunately I cannot attend the next IETF meeting as it
    David> clashes with Openstack in Honk Kong (where I am also giving a
    David> presentation on Federation). But the first meeting next year
    David> could be suitable
In preparing a presentation, I'd ask that you focus a lot of effort on
    David> describing your assumptions.  We found when discussing trust
    David> router that you had a different set of assumptions than the
    David> rest of the room and until those assumptions were described I
    David> found myself rather frustrated.

I can already tell we're going to have similar issues with this
discussion.
As an example, in an earlier message, you stated that the SP is the only
party that  knows what attributes the SP needs.

There are cases where that's true, but one of the major motivations
behind the COI concept in Moonshot is to move knowledge about what
attributes are required around so that the IDP has more information
about this.

Similarly you propose that authentication happen prior to deciding what
service of a multi-service SP is used.  That's one approach, but it has
a lot of problems.  One is that you may want a different federation
fabric to use for different services.

I believe you're stating things as facts that are simply one
decomposition of the problem space.
I don't mind examining that decomposition of the problem space.  If
there are enough folks interested in writing code and specs and
reviewing them, I think doing work there could be very interesting.
However, I think it's also important to understand that decomposition
involves a lot of complexity.  There are alternate organizations of the
relationship between SP and IDP that may work better in different
environments.
I think understanding when complexity is necessary is quite desirable.

--Sam