RE: [security-bindings] web browser profile document..

[Irving Reid <Irving.Reid@baltimore.com>]

I may not be able to attend the conference call; I'm out of the office until
after the F2F next week.

Page 2, lines 1-2 (section 1.1.2):
Given the "relying party tailors assertion" changes, the artifact no longer
unambiguously identifies an assertion to the source site. Instead, the
artifact identifes a <mumble> about which the source site can issue
assertions. The <mumble> might be called a session, or an authenticated
principal, or something like that; session seems the most natural, but is
likely to cause confusion.

Others have commented on P.2, lines 17-21. For (a), we could clarify it by
either specifying a 20 byte random number, or saying that at least eight
random bytes must be padded out to exactly twenty bytes, and the entire
twenty bytes is considered to be the handle. For (b), we could say something
like:

(b) The value is the SHA-1 hash of some data known only to the source site.
It must not be possible to derive this data from the corresponding
assertion.

That said, I don't see a lot of value in providing the alternative. In order
for (b) to resist attack, it pretty well needs to have strong randomness
mixed in anyway. Given that, why not just use the random number to begin
with?

Page 4, line 42: do you mean "assertion referenced by the artifact" rather
than "... assertion"? Also, there had been some debate about whether the
query would contain the entire artifact, or just the handle. I thought the
decision was handle.

Page 4, lines 44-45: There is no "assertion not found" error; according to
the protocol spec, we could either return success with zero assertions, or
"Failure".

About 1.1.4.1 in general: the SAML Artifact profile allows more than one
artifact to be passed on a single HTTP request. Do we wish to apply any
restrictions, such as that all artifacts must have the same PartnerID? The
use cases for anything else get convoluted quickly.

Page 7, lines 22-24: I disagree with putting these requirements on the
assertions. Aside from adding complication to both asserting and relying
parties, it also makes it more difficult to use the resulting assertions in
a mixed environment. It would be nice if a web application could take the
assertions it got through a SAML browser SSO and attach them to a B2B
message flow, but these profile-specific MUSTs make such implementations
more difficult.

Page 9, lines 12-13: As above, adding this ConfirmationMethod requirement
makes SAML less useful.

> Here is the web browser profile document. I have attempted
> to include text for the relying party tailors assertion
> case in the simplest possible way. The key issue is
> that instead of making two roundtrips the RP can make
> a query for additional assertions at the same time
> when obtaining the referent of the SAML artifact.
> 
> Even this raises some difficult issues which are
> unresolved: suppose
> the attribute query component includes attributes that cannot
> be found at the AP. What should the AP return? 

Same as if the request was by subject name - depends on whether the RP
requested any attributes, or all. Either an assertion with only some of the
attributes, or a failure.

> In general, the issue of error states is a complex
> one and one that we have not yet plumbed.

Then I guess we'll have to get plumbing.

 - irving -


-----------------------------------------------------------------------------------------------------------------
The information contained in this message is confidential and is intended 
for the addressee(s) only.  If you have received this message in error or 
there are any problems please notify the originator immediately.  The 
unauthorized use, disclosure, copying or alteration of this message is 
strictly forbidden. Baltimore Technologies plc will not be liable for direct, 
special, indirect or consequential damages arising from alteration of the 
contents of this message by a third party or as a result of any virus being 
passed on.

In addition, certain Marketing collateral may be added from time to time to 
promote Baltimore Technologies products, services, Global e-Security or 
appearance at trade shows and conferences.
 
This footnote confirms that this email message has been swept by 
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.