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