>> I'm curious about the requirement to authenticate to the responder.
>
> It's to provide trust in the assertion. If you don't care who the
> issuer is,
> then you can "authenticate" them however you like and I suppose if the
> issuer only wants to support such relying parties, it can do so by
> "not"
> authenticating itself.
I see the source of one of my confusions. I read "responder" and I
inferred "HTTP responder" instead of "SAML responder". I got the
layers tangled.
(I also got my browser tabs mixed-up, and I read part of the HTTP
Artifact Binding text thinking it was from the Artifact Resolution
Profile...)
>> For example, imagine an SAML artifact format that carried a hash of
>> the SAML message. The requester could verify post hoc that the
>> resolved assertion was genuine by calculating the hash and matching
>> this value to the value in the artifact.
>
> Yes, but it wouldn't prove that you got either one from somebody you
> trusted
> and not some arbitrary interloper.
Sure, but we can authenticate the binding used to obtain the artifact
to obtain that assurance.
>> If a binding where to use this mechanism, would this violate the
>> requirement set out above?
>
> Probably in the strictest sense, but really any of the security
> requirements
> can be turned into no-ops by claiming you "did it by ignoring it".
I originally thought there was a violation because I got badly
confused. Where is the violation now? The callback does not require
authentication...?
josh.
