RE: [security-services] NZ gov use case (SP - IDP (where logon se rvice and Identity Verification Service are hypothetically one and the same)

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

> Typos on step 3..should have read IDP for the challenge/response steps, of
> course.
>
> Step 5 is not clear either. Step 5 sees the IdP (in this case the
> hypothetical Government Online Authentication Service - GOAS) present an
> HTML page to the Principal.

Ok.

> So that said, I think I'm getting the sense that provided we could locate
> product/s that supported multiple assertions (in this hypothetical case,
> an identity assertion and an authentication assertion), we would be OK.

If you mean an attribute assertion, I don't think you have a problem finding
that...everything pretty much handles bundling attributes during SSO.
Usually with one assertion, but I've seen two, which was something we did as
a default for some questionable reasons.

But real-time release is a whole other thing. There are UI issues, usability
concerns, and so forth, and nobody has to support that to be compliant. If
you want it, you gotta tell your vendor that if they don't have it now or
permit enough hacking to do it.

> I don't have enough knowledge to comment on your suggestion of a query
> extension but I *think* it sounds like one way to increase the chances of
> product support for this sort of use case in future?

Pushing attributes assumes the IdP has enough data to know what to put in
the assertion(s). You have to either preconfigure it, go fetch policy
(metadata), which can be somewhat static and limiting, or put it in-band.
The SAML 2.0 AuthnRequest supports it in metadata, but not in-band.

Of course, you could theoretically just make it the user's problem to select
what to include, but that isn't really viable much of the time, and it just
pushes the policy awareness problem to the client.

-- Scott