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] A browser/POST question...


I feel uncomfortable allowing a MUST NOT statement to be added at the 
last minute without a proper discussion or vote, particularly since the 
absence of a statement now is essentially a MAY and this change would be 
semantically backwards incompatible.

I would be reluctantly okay with adding a sentence that says SHOULD NOT 
and carries a "comment note" asking for feedback during last call. 
Someone would need to supply me with the exact sentence to add by the 
end of the day today.

By the way, line numbers are becoming a bit unreliable as an addressing 
mechanism because of the track-changes and other weirdnesses, so if you 
can "anchor" any comments to nearby text or section headings, that would 
be helpful.  Thanks!

	Eve

Scott Cantor wrote:
>>In the browser/artifact profile, we now say that ConfirmationData SHOULD NOT
>>be supplied.  But in Browser/POST, we say nothing about ConfirmationData. I
>>looked back through the mail archive, but couldn't find a conclusive
>>statement.  For consistency and completeness of the B&P spec, I think we
>>should provide a normative statement about it.  I've assumed MUST NOT
>>applies, but then I haven't thought about it a lot.  So is ConfirmationData
>>a "MUST NOT", "SHOULD NOT", "MAY", or something else?
> 
> 
> I hadn't considered the possibility until Irving made a comment at the presentation we gave this week, but one *could* put a key in
> there and tie that to an SSL client certificate as a way of restricting the validity of the assertion, while relieving the target of
> the burden of validating the cert. But that wouldn't really be a bearer assertion any more, and the profile dictates use of Bearer
> rather than Holder of Key.
> 
> So I'd think that as currently defined, it ought to be a MUST NOT, but could be revisited in 2.0 to permit such a use case if
> there's interest.
> 
> -- Scott
> 
> 

-- 
Eve Maler                                        +1 781 442 3190
Sun Microsystems                            cell +1 781 354 9441
Web Technologies and Standards               eve.maler @ sun.com



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