>>>>> "Josh" == Josh Howlett <[email protected]> writes:
>> 1) I think we should say somewhere that you shouldn't send back
>> multiple assertions unless it's appropriate to just combine them
>> together. I.E. assertions from the same IDP about the same
>> subject are probably OK, at least until we figure out what we
>> want to do in those cases.
Josh> I think we need to be circumspect how we choose to constrain
Josh> the protocol. If we need it for technical interoperability,
Josh> fine. Otherwise I'd prefer to leave anything to do with the
Josh> semantics of the messages to the application to worry about. I
Josh> don¹t think its the business of the transport or framing to
Josh> dictate that.
In principle I'd agree with you. However in practice I think it is very
difficult for the application to understand these semantics in an
interoperable manner (something we very much need applications to do)
unless the framing explains that to the application. I have no problem
introducing a semantics code or purpose code or something so we can
define new semantics in the future and reuse the framing. However the
semantics fairly clearly need to be nailed down well enough to
understand whether we can use the naming context implied in
draft-ietf-gss-eap-naming.
That context today only deals with attributes and SAML messages that are
about the subject of the authentication vouched for by an IDP
sufficiently tied into the authentication process that the RP need not
care about the distinction.
If you throw in an assertion about someone else, or from someone else,
we don't know how an application should interpret it; we won't be able
to write interoperable applications in that case. Also, even if you
throw in an unrelated SAML message, we won't know how to process it.
Even if in some cases such information could be distinguished with
careful application of metadata, it's far easier for the sender to
explain what the sender is doing than for the recipient to try and
interoperably infer it.
--Sam
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
