Re: [security-services] Attribute Sharing Profile

["Tom Scavo" <trscavo@gmail.com>]

On 8/29/06, Ari Kermaier <ari.kermaier@oracle.com> wrote:
>
> Regardless, I think Enhanced mode was originally all there was to this profile -- Basic mode was added for generality's sake.

That's correct, but the use case description in the original document
motivates Basic Mode, not Enhanced Mode.  That's my point.  Enhanced
Mode is the focus of the original profile, but it is not properly
motivated, therefore some of the requirements are difficult to
justify.

> As an aside, this has brought to mind a question about SAMLCore -- what are the uniqueness requirements, if any, for Attribute{Name, Format} elements within a single AttributeStatement, across AttributeStatements within a single Assertion, and/or accross AttributeStatements in multiple Assertions in a single Response? I.e., how is the SP to interpret receipt of two Attribute elements with identical Name and Format, but having different AttributeValue child elements? Is it equivalent to receiving a single Attribute element with the union of the two sets of AttributeValue elements, or is it an error, or is it deployment/use-case dependent?

Good questions!

> > > > [section 4] Evidently, both the <Response> and the
> > <Assertion> MUST be
> > > > signed (lines 194--195 and lines 250--251, resp.).  Is this really
> > > > necessary?  I suggest the <Assertion> MAY be signed if
> > the situation
> > > > warrants.
> > >
> > > The original proponents of this profile continue to insist
> > that both the Response and the Assertion MUST be signed.
> >
> > I haven't heard anything one way or the other.  Are you in
> > communication with the originators of this profile?
> >
> > > Is there a reason you feel this requirement needs to be relaxed?
> >
> > Without a reasonable use case for enhanced mode that can be analyzed
> > in terms of its security requirements, I simply don't understand the
> > current signature requirements.
>
> This is a hard requirement of the profile's originators, to support processing models where Response processing/verification is performed by one system entity, after which the Assertion is stripped out and processed by a second system entity. Also, the generator of the Response might be a distinct entity from the generator of the Assertion, and so the signing keys could be different.

Certainly, but why is this a MUST?  There are a lot of "ifs" in the
previous paragraph.  Why force these security requirements on
deployments that might not benefit from them?

Tom