Re: [security-services] comment on saml-loa-authncontext-profile: remove 800-63 schemas

["RL 'Bob' Morgan" <rlmorgan@washington.edu>]

Let me just say that I understand that people really want expressions of 
assurance to happen, so are working with whatever is there.  In the 
university context there are some RPs, not even using SAML or federation 
per se, who want to set push some assurance standards on their "IdPs", and 
have pointed at 800-63 to do so, leading to university auditors who might 
be familiar with PCI DSS, trying to make sense of 800-63, with poor 
results.  Our friends at the GSA see the problem, but as far as I can tell 
are not inclined to re-create the full E-Auth program given its past 
problems.  So we have something of an assurance gap.

I don't know hardly anything about PCI DSS, but I wonder if there are 
people who would want whatever it does to be expressed as SAML LoA?

> 1) can you point me to the corresponding URIs?

The technical stuff for the InCommon assurance program is about to enter 
our equivalent of public review, but hasn't been made public yet.  Text is 
below.  As Scott mentions, it's currently a SAML 1.1 federation, so we're 
going to use a SAML attribute we've defined for the purpose to carry the 
assurance URIs.  As I wrote before, we haven't made a decision on how it 
would work with SAML 2, but I think we have to do so shortly.  It would 
seem odd to me not to use this TC-defined profile, but ...

> The AC class mechanism would have us (or InCommon) jump through the hoop 
> of defining a set of class schemas that then linked to the profiles 
> through the <Documentation> kluge ..
>
> 2) Is linking to the profiles, directly or indirectly, the right thing? 
> Should we not link to appropriate sections of the InCommon framework docs, 
> i.e. to ensure that the profiles are interpreted in the context of the full 
> IAAF?

I don't understand your point here, but maybe what we could do to help 
with this is prepare a separate doc defining the use of this LoA schema in 
the InCommon assurance program, as a template for other programs to 
follow.  But for this doc I'm thinking that an example.com-type example is 
the best thing.

  - RL "Bob"

---

In the eduPerson schema[1], the eduPersonAssurance attribute is specified 
for inclusion in identity assertions to indicate to relying parties that 
an assertion has been issued under the conditions of a particular identity 
assurance profile.  InCommon defines values for the eduPersonAssurance 
attribute for use with the profiles defined in the InCommon Identity 
Assurance Framework.  These values are:

     * http://incommonfederation.org/assurance/silver :  indicates Silver
       profile
     * http://incommonfederation.org/assurance/bronze :  indicates Bronze
       profile

An InCommon Identity Provider which has been certified via the Framework 
has its entity information included on an informational web page:

     * http://incommonfederation.org/assurance/silver/ :  for Silver
       profile
     * http://incommonfederation.org/assurance/bronze/ :  for Bronze
       profile

(Note:  more formal technical means of indicating assurance status may be 
provided in the future.)

[1] 
http://middleware.internet2.edu/eduperson/docs/internet2-mace-dir-eduperson-200806.html