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


Tom,

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

Your proposed text in the last message is fine by me here.

> The SAML wiki provides a fairly good version history (or at least it
> contains the information required to construct one easily).

Maybe pointing at the Wiki would be better, then.  It lacks my  
comments that I've been adding with revisions, but those would only  
take a few moments to copy over.  As an aside, I really appreciate  
your effort keeping this maintained.

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

As we discussed on the call, it really doesn't.  I still have no  
strong use case for this, but that alone is not reason enough to add  
any restriction.  I'll remove it in the next draft.

> I'm including the text here for reference:
>
> "If the user agent cannot satisfy the <saml:SubjectConfirmation>
> present in the <samlp:AuthnRequest>, or it fails to obtain a key from
> the user agent, the identity provider MUST respond with a
> <samlp:Response> message containing an error status and no
> assertions."
>
> 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.

We discussed this pretty thoroughly on the call, and I think the text  
proposed in your last message is a great phrasing of the conclusions  
that came out of that.

>>> - [lines 445--446] What is a "uniquely identifying <saml:NameID>"?
>>
>> A uniquely identifying <saml:NameID>, e.g. one that refers to a  
>> specific
>> principal at the IdP.  From my perspective, I don't think I can  
>> pick any
>> clearer words.
>
> Sorry, this paragraph makes no sense.  First, a <saml:AuthnStatement>
> element doesn't contain a <saml:NameID> element, and second, why would
> the IdP *not* assert a NameID "that refers to a specific principal"?

Not directly included, of course, and I see your point on the  
specific principal.  This will be removed in the next draft.

>>> - [line 297] s/spoofing/initiating/
>>>
>>> - [line 300] s/spoofed/initiated/
>>
>> Not proper spec language, huh?  Can I use "forgery"? :D
>
> The word "spoof" has connotations.  Are you trying to convey some
> hidden meaning with these words?  If so, it's probably better to be
> explicit.  If not, I think you should choose more benign wording.

No, I picked "spoof" because it accurately conveyed what was done.  I  
don't shy away from using such words with silly intentions in my  
other writing, but obviously a spec is not a place for humor.  I was  
just poking fun at myself with this comment, because I should've  
caught that myself.

Just having a fun time going through the standards process for the  
first time,
Nate.


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