Re: [security-services] Trust in artifact resolution

[Josh Howlett <josh.howlett@gmail.com>]

>> 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.