RE: [security-services] BPP vs BAP for SAML 1.1

[Scott Cantor <cantor.2@osu.edu>]

> The benefit of BAP is that we are able to include additional attribute
> statements in the assertion that can contain sensitive data. We do not
> have to worry about this information being exposed in the browser. 

Just to get all the variables on the table, we (meaning Shib) obviously
address this by doing an attribute query subsequent to the POST. This is an
extra call, but since artifact is also an extra call, there's no difference,
which leaves the signing as the major cost (and as you note in ID-FF it's
signed anyway). We also can refresh attributes within a session with that
approach, which gives the attribute authority some control over freshness.

> The one implementation hurdle we (and any other highly available IdP)
> have to overcome for BAP is the artifact rendevous problem. 
> Implementors must consider how to ensure the artifact that is returned to 
> the IdP in one physical location can find its way back to the location 
> where it was orignally created. This is problematic when the IdP has
> multiple connections to the Internet.

I think Greg (Whitehead) had some bright idea about how to embed something
in the artifact to help address this, but I can't recall what it was. The
state involved is definitely why I dislike the profile. If Burton is to be
believed, vendors haven't exactly addressed it in a fashion that leads to
robust deployments either (but I'm not speaking from experience).

I think it's an overall better situation if both profiles (soon to be
bindings I hope) are supported and recognized as having different strengths
and weaknesses. That seems to be happening now, which is an improvement.

-- Scott