Assurance

["Jones, Mark B" <>]

My "in the broader marketplace" comment was a response to Joe's 
question/comment:

"What of the broader marketplace? Is Facebook or Google likely to adopt 
credentials that follow *either* the federal standard, or higher education's 
standard for strong assurance credentials? Unfortunately, probably not."

The fact that Google and others have gone to the trouble of becoming ICAM 
approved is evidence that 800-63 is gaining traction as a standard "in the 
broader marketplace".  And from my perspective the acceptance of InCommon as 
an ICAM approved trust framework means that we are all contributing to the 
move toward 800-63 in Higher Ed.

And I see this as a good thing for collaboration, security, and privacy.

As far as 800-63 being harder to implement in academia...
I have not heard any grumblings about this at my institution so I'm not sure 
what you are referring to.

-----Original Message-----
From: 

 
[mailto:]
 On Behalf Of Roy, Nicholas S
Sent: Thursday, August 09, 2012 3:21 PM
To: 

Subject: RE: [Assurance] RE: [confluence] InC-Assurance > Remote-Proofing 
Approaches

"Google and others "in the broader marketplace" are in fact adopting ICAM: 
http://www.idmanagement.gov/pages.cfm/page/ICAM-TrustFramework-IDP";

Google and others in the marketplace don't have faculty, staff and students 
on their network demanding open access to/from the public internet from their 
workstation.  That's one difference between an academic institution and 
Google that makes 800-63 very much harder to implement in academia.  The 
AD/Silver cookbook is an attempt to bridge the gap between current practice, 
what's feasible in academia, and Silver.  Even with that, there are things in 
800-63 which make using a technology like Active Directory in an environment 
you want to be Silver compliant very difficult.  There are other similar 
corporate/locked-down vs. academic/open problems.  Silver itself is an 
attempt to bridge that divide, I think.

Nick

-----Original Message-----
From: 

 
[mailto:]
 On Behalf Of Jones, Mark B
Sent: Wednesday, August 08, 2012 3:58 PM
To: 

Subject: RE: [Assurance] RE: [confluence] InC-Assurance > Remote-Proofing 
Approaches

I think this is about picking a standard for identity proofing and credential 
issuance and working with it.

Google and others "in the broader marketplace" are in fact adopting ICAM: 
http://www.idmanagement.gov/pages.cfm/page/ICAM-TrustFramework-IDP

I think we will have a standard and that many have already settled on 800-63.

 

-----Original Message-----
From: 

 
[mailto:]
 On Behalf Of Michael R. Gettes
Sent: Wednesday, August 08, 2012 12:45 PM
To: 
<>
Subject: Re: [Assurance] RE: [confluence] InC-Assurance > Remote-Proofing 
Approaches

Joe, we are not exactly saying different things.  HSPD-12 doesn't necessarily 
imply that Higher Ed contracts will have to have federal creds.  This is why 
the feds have been pursuing alternative mechanisms like NSTIC.  There was a 
time (about 10 years ago) when there was lots of discussions within the fed 
to have them (USgov) issue citizen creds... well, as we all know, that hasn't 
happened.  NSTIC and other avenues have happened.  Will there be a standard?  
I think not.  Will there be a network of trust arrangements of which InCommon 
will be part of that fabric?  I think so, since it is already happening.  I 
appreciate, from a security perspective, having one answer is desirable - 
just as those who believe there should be some national identifier.  I am not 
in favor of such things.  I am in favor of interoperable standards and 
contracts/agreements.  Is it messier?  Well, yes.  In the end, I believe it's 
a healthier path.

/mrg

On Aug 8, 2012, at 12:21, Joe St Sauver wrote:

> mrg commented:
> 
> #800-63 is a useful document.  It is intended for USGov agencies and NGOs.  
> #We are not they.  When we say Silver is 800-63, even in certain respects, 
> #I completely disagree.   We are NOT they.  
> 
> At the risk triggering special paper airplane targetting when we next 
> eat together, let me just share a somewhat different perspective...
> 
> Clearly, higher ed is not the US government, in that respect, you're 
> absolutely right.
> 
> However, in many cases, we do need to work closely with them. This 
> might be NSF or NIH or DOE research grants, for example, or use of 
> supercomputers or other federally administered research facilities.
> 
> Or it might be federal financial aid programs, or other 
> student-related programs in conjunction with the Department of 
> Education, just to mention another possible area where universities 
> and federal agencies seem to often intersect.
> 
> If we're all following the same standards, imperfect/frustrating 
> though those existing stanard may be, we might hope that those 
> interactions would be simpler (probably a vain hope, but at times I 
> indulge myself and allow myself to be at least a little bit of an 
> optimistic idealist).
> 
> Heck, if the international community can agree on common standards for 
> machine readable passports, or the states can (largely) agree on 
> common standards for drivers licenses, surely we should be able to 
> come close to similar congruence for high assurance identities...
> 
> Or we might do something different, unique to (part of) higher ed. 
> 
> Having done so, is there much chance that the feds will come about and 
> begin to follow our new course? I think not. HSDP-12, for example, 
> ensured that virtually all federal employees and contracts will be 
> using HSPD-12-compliant credentials. That ship has sailed.
> 
> What of the broader marketplace? Is Facebook or Google likely to adopt 
> credentials that follow *either* the federal standard, or higher 
> education's standard for strong assurance credentials? Unfortunately, 
> probably not.
> 
> And that's really unfortunate. I'd really, really, really like to see 
> a standardized and potentially interoperable credential for all those 
> who might need or want it, with privacy preserving options for those 
> who might worry about privacy/big brother having too easy of a time of it.
> 
> If we can't do 800-63, I think it would behoove us to pursue a formal 
> industry standard that we all could live with, probably via the IETF.
> It might start with 800-63, or Silver, or something else, but at least 
> it would be a standard from a standards body that has a chance of 
> universal acceptance. That's the real key, I think -- having something 
> that's standardized, and thus broadly accepted.
> 
> Just my two cents, paper airplane ack-ack guns at the ready :-)
> 
> Regards,
> 
> Joe