>>>>> "Josh" == Josh Howlett <[email protected]> writes:
>>>
>>> OK. So, we're telling people that they should confirm that the
>>> realm portion of the NAI is in the response or metadata for the
>>> IDP, but we have no way to express that name in either
>>> interoperably?
>>>
>>> That's possibly OK, but might need to be called out.
>>
>> Or define something, yes. There are reasons to think something's
>> going to be needed. Realm-based discovery seems likely to be the
>> path forward in other areas.
Josh> Having reflected on this some more, I'm now a bit ambivalent
Josh> about the whole discussion in 5.3.2. The text is assuming a
Josh> particular SAML deployment model (policy & configuration in
Josh> signed and trusted metadata) that will be true of some
Josh> deployments but not others (e.g., a SAML proxy
Josh> infrastructure).
Josh> I am pretty sure that rewriting this text for the general case
Josh> would yield text amounting to "use technical methods to
Josh> validate that names claimed by other SAML entities are true,
Josh> to whatever standard constitutes true for you".
Unfortunately, I think the above is a compelling argument why we need
something reasonably specific.
Because in your restatement you've lost the essential security issue.
It's not enough that we claim that SAML entities names are true.
That's actually not addressed by my reading of 5.3.2.The tricky issue is
making sure that when SAML entities produce messages, they intend to
allow the AAA entities discussed in 5.3.1 to use those messages.
This is more of an issue of GSS-API channel binding than it is SAML
naming.
Ultimately the SAML naming is a convenience for associating policy with
a SAML message. I don't think it does more than that except in so far
as names are also attribute-like.
Section 5.3.2 is attempting to discuss the importance of making sure the
policy is appropriate for this channel as well as appropriate for the
named SAML entities however that's handled.
--Sam
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
