[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [security-services] comment on saml-loa-authncontext-profile: remove 800-63 schemas
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]