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

On Mon, Jul 14, 2008 at 11:01 AM, Scott Cantor <cantor.2@osu.edu> wrote:
>> 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 think that would be good.

>> 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.

Okay, that's fine, but that's no reason to persist poor language in
this spec.  The latter should be as correct and accurate as it can,
regardless of its cousin profile.

> 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.

Well, for what it's worth, I reviewed Core and the schema yesterday,
and there didn't seem to be anything that precluded an empty h-o-k
SubjectConfirmation element.

>> 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.

That's my point, an RP *can* examine the certificate further, there's
nothing to prevent them from doing that.  They're not required to do
so, however, and if they choose to do so, they risk interop for sure.
But hey, there are plenty of non-interop scenarios in production
today.  Such is the nature of the beast.  People do what they think
they need to do to make things work the way they think things should
work.  It's not our job to tell them otherwise.


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