OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [security-services] comments re sstc-saml-holder-of-key-browser-sso-draft-07

> Suppose, for example, an IdP issues an authn assertion and an
> attribute assertion (which is not unlikely).  What is your advice
> regarding the subject confirmation of both assertions?

I assume it's the same as SSO now. You only accept assertions (for the
purposes of the profile) if you can confirm them in the manner you

If you're requiring HoK, you only accept the HoK assertions. Any others
would be ignored or treated as excess baggage to be tracked in case some
other profile plans to leverage them after SSO.

> > Yes.  I can't think of a meaningful use case for a non-trusted
> > <saml:Subject> in an <samlp:AuthnRequest> under this profile.
> Sorry, I must be missing something.  A <saml:Subject> in the request
> is simply asking for a strongly matching <saml:Subject> in the
> response.  Why does that require the SP to authenticate to the IdP?

I agree. 

> I don't know what it means for the user agent to "satisfy the
> <saml:SubjectConfirmation> present in the <samlp:AuthnRequest>."  All
> I know is that the IdP must issue an assertion containing a
> <saml:Subject> element that strongly matches the <saml:Subject>
> element in the request.  Now the meaning of "strongly matches" is
> sufficiently vague that I wouldn't dare to characterize it, but saying
> that the user agent must "satisfy the <saml:SubjectConfirmation>
> present in the <samlp:AuthnRequest>" is just adding fuel to the fire.

I think the language you want here is reversed. The requirement (which I
thought was implied by core) is that the IdP mustn't issue the assertion
unless it is confident in the user agent's ability to satisfy it. This isn't
a hard concept, it's just hard to document. The point is that you have to
authenticate to the IdP in a manner that "supports" the eventual assertion.

> Sorry, I should be more consistent with my comments.  In my defense,
> we did not have a Metadata Interoperability Profile on 2 Sep (or at
> least one whose scope I understood).

You don't want this profile to depend on mine, but moreover, you can't
assume that metadata will be used in a specific way. Nor should you. If the
underlying trust evaluations aren't interoperable, well, that's life. That's
why the specs are modular.
> There is no guidance in the metadata spec regarding the
> WantAssertionsSigned attribute, for example.  This is perhaps as it
> should be.  Does this belong in the Metadata Interoperability Profile?
>  If not, I don't see any alternative but to profile it here.

If you say you want them signed, you're simply warning the IdP that not
signing it is likely to produce a failure later. I don't understand what's
so vague about that.
-- Scott

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]