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: sstc-saml-holder-of-key-browser-sso-draft-03


> In practice, does a signed AuthnRequest exceed the size limitations of
> URLs?  I thought so, which is why I made that comment.

No, not in general. You just can't pass certificates in the message.

> It strikes me that these lines are the essence of this profile (in a
> single sentence).  I was disappointed to read them on page 11.

Maybe reinforce them by mentioning them in the introduction or overview?

> I see that now, but I think that's wrong.  At the risk of preaching to
> the choir, the basic task of the SP is to accept and process the
> assertion.  Access control is out of scope.

I know, but I think it's too late and the disadvantage of making the
language different for no reason outweighs being pedantic about it.

> It doesn't seem right to me.  Can you give an example of an SP that
> does not provide a security context?  Not doing so prevents the access
> control mechanism downstream from arriving at a decision.

An SP that's "part of" a resource, I suppose. If it's all one step.

> Okay, that's fine.  If the IdP sees a h-o-k SubjectConfirmation
> element in the request, regardless of whether or not a KeyInfo is
> included, it knows this profile is required.  But now that I think of
> it, maybe that's dangerous since other h-o-k profiles may exist in the
> future.

Yes, I would agree with that concern. I don't think that's a sufficient
signal.

> No, I'm talking about the request, not the response.  I'm suggesting
> the SP insert an empty h-o-k SubjectConfirmation element in the
> AuthnRequest.  But yes, I think you're right, this is not general
> enough.  Metadata is required.

I understand (and agree), but the point is that the request syntax for
confirmation method is not different from the response. The spec for HoK
syntax says you have to have one or more, so that's kind of that.

There's nothing I can recall in the AuthnRequest section in core that says
"you can send only part of the confirmation method" or that you can leave
out the data.

> > I think it can be reworded a bit to permit what you're suggesting
without
> > causing a problem. The danger is in people implementing the profile in
such
> > a way that the certificate has to be "valid" in order to satisfy the
> > profile-defined processing rules for satisfying the confirmation. We
wanted
> > it to be specifically NOT legal for an SP to do anything with the
> > certificate in the context of deciding whether to accept the assertion.
> 
> Then why not define what it means to "valid" with respect to this profile.

I think it does that now, but if you want more wiggle room, it needs to be
relaxed somewhat.

> If you're explicit about what's required (and I think you've mostly
> done that), the rest is simply out of scope.

I think that's ok, but from experience, I know that if you don't *say* you
can't examine the certificate, people will. The trick is in defining the
sense in which you can examine it, distinct from this profile.

> > If an SP says that it will sign in metadata, you know to reject anything
> > that isn't signed.
> 
> This is an aside, but I don't get that impression by reading the metadata
> spec.

We clarified that in errata pretty explicitly.

-- Scott




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