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

["Conor P. Cahill" <concahill@aol.com>]

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:cantor.2@osu.edu]
Sent: Thursday, June 09, 2005 3:35 PM
To: 'Thomas Wisniewski'; security-services@lists.oasis-open.org
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