RE: [security-services] Authentication Response IssuerName vs. As sertionIssuerName

I am concerned about making this a must.  While I think there are
benefits from having this there, I think there are also very reasonable
cases where it doesn't add any real value.  In our case, where we will
typically have unsigned responses, any issuer carried in the response
would be untrusted, but the issuer in the assertion would be trusted
because we would sign the assertion.

Note that I am *NOT* saying that it should not be carried, just that we
shouldn't make unnecessary information mandatory.  

The current wording "issuer MAY be omitted" is essentially an  "issuer
SHOULD be present" (perhaps not exactly, but I wouldn't object to
saying it SHOULD be there, especially if it was somehow caveated with
"when the response is signed" or something like that).

Conor

Thomas Wisniewski wrote on 6/9/2005, 3:43 PM:

  
I guess that's
reasonable. Is there strong objection to making it mandatory in the SSO
Response?
  

  
  
As an implementer,
not having it there really stinks since you cannot handle the protocol
layer the same way (or without digging down into the Assertion :-(

  
  
Tom.
  

  
  
-----Original
Message-----
  

  From: Scott
Cantor [mailto:] 
  

  Sent: Thursday,
June 09, 2005 3:35 PM
  

  To: 'Thomas
Wisniewski'; 
  

  Subject: RE:
[security-services] Authentication Response IssuerName vs. Assertion
IssuerName
  

  

  
  
> Yes, then
there's an errata. Line 541 in profiles. Basically
  

  > says
issuer (for an AuthnRequest Response) MAY be omitted. I 
  

  > believe
this is the only spot in profiles.
  

  > 
  

  > Jahan, can
you add an errata item to change line 541 to
  

  > 
  

  > "the
<Issuer> element MUST be present and MUST contain the
  

  > unique
identifieir of the" 
  

  > 
  

  > The main
reason is that Issuer should should be a MUST in the
  

  > SSO
Response protocol. 
  

  
  
Ah, ok. So I think
the point there was to allow people to assume Issuer based on the
Assertion, thus your point about encryption...

  
  
A compromise might
be to just say, if you encrypt the assertion, it's required, otherwise
it MAY be omitted.
  

  
  
-- Scott