Date: Thu, 28 Mar 2024 22:55:27 +0000 (UTC) Message-ID: <2088711115.7145.1711666527189@ip-10-10-7-29.ec2.internal> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_7144_1902579626.1711666527188" ------=_Part_7144_1902579626.1711666527188 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
notes, social identity call, 3/28/2011
TOPIC -- Mgmt: Assessing Risk: Matching Technologies to Resource Access = Risks
Dedra pointed the group toward OMB 04-04
http://www.whitehouse.gov/sites/def= ault/files/omb/memoranda/fy04/m04-04.pdf
which is the foundation for the US Federal government's work on risk and= Levels of Assurance. Section 2 contains useful suggestions on how to asses= s risk. It identifies several categories, and provides guidance on mapping = low, medium, and high risk in these categories to an appropriate required L= oA.
Inconvenience, distress or damage to standing or=
reputation
Financial loss or agency liability
Harm to agency programs or public interests
Unauthorized release of sensitive information
Personal Safety
Civil or criminal violations
There was a brief summary of how InCommon Silver and Bronze map to NIST Le=
vels 1 and 2, and the business process that results in IC asserting that a =
campus meets teh Silver criteria (ie campus IT organization writes up why i=
t thinks the campus meets silver criteria; auditor reviews that document an=
d the policy, business practice, and technology the campus uses to meet the=
criteria; auditor writes letter with opinion as to whether of not the camp=
us is meeting the criteria; if letter is positive then the letter is sent t=
o IC; IC reviews the letter and decides whether or not it i sufficient.)
Discussion followed about current situation. Dedra asserted that SPs wou= ld want to differentiate social loa 1 identities form campus asserted loa 1= identities. There was also discussion of account linking -- linking a soci= al identity to a campus-asserted silver account -- would this process have = any impact on loa of social account ? CONSENSUS -- NO
Steve Massover asserted that loa is orthogonal to differentiating social= vs enterprise identities. He suggested that the key issue is whether the i= dentity provider "in a trust federation" vs not a member (where trust feder= ation currently means a higher ed trust federation, rather than something l= ike OIX). Nate and Keith agreed.
-- Nate suggesting that metrics we're trying to use may not be sufficien= t to the problem at hand. Socials are on loa 1 today, but equifax and paypa= l are aiming higher. The conversation might be better framed around metrics= that were sufficiently granular to allow differentiating social from enter= prise level 1; the group should explore ways to express the difference.
keith -- won't have loa 1.5 available to us anytime soon
mention that google may at some point begin asserting that an authentica= tion event was done with 2-factor; it was noted that this was technology, n= ot LoA.
CONSENSUS -- relying parties will want to know more than just the = LOA.
CONSENSUS -- IDPs will probably have to assert LOA, may need to also ass= ert social vs enterprise
What needs to be asserted ?
-- Nate suggested that SPs should NOT care about=
the protocol; they should only care about something akin to LOA
-- Dedra stated that her SPs want to know that if =
this is loa 1 and a social identity...
Nate -- GW could say "we don't know whether this a=
uthn was done over ssl"
Keith -- likes Chris' approach of asserting NO LOA=
(just missing)
Steve C -- SPs won't implement complex algor=
ithms, just a couple of differentiators
Steve M -- agree, anything more complicated is pro=
bably beyond them at this point.
Steve C, Steve M -- over time, this will change, but no=
w is not the time to provide or use any more finer grained differentiator..=
.
CONSENSUS -- seemed to be "if provider asserts LoA then the GW should pa= ss that value through; the GW should not attempt to develop or compute an L= oA based on the information available to it; the GW SHOULD assert whether t= he identity provider is a social provider or a campus."
----------
TOPIC -- Mgmt: Tradeoffs: How Do I Choose My Approach
Quick notes on protocols used by various social identity providers:
yahoo is an openid provider
google can be an openid provider, and they will accept =
openid from yahoo;
facebook is oauth; however, they don't force their=
users to use ssl (use ssl during authn, but not during session, so others =
can hijack the session cookie)
How can SPs actually use these providers? What PII does each share ?
-- Chris Hubing has doc on what his SP accepts fro=
m various providers, and his algorithms
https://wikispaces.psu.edu/display/EmergingTechnologies/OpenID+Impleme=
ntation+for+WikiSpaces
-- only accepts if email addres=
s matches domain name
-- some people are willing to v=
et people out of band, and accept that, even if they don't match; Chris won=
't accept that, tho
-- Chris's GW doesn't pass any =
LOA INFO RIGHT NOW
Dedra stated that the info provided by the social =
providers dedra needs to be mapped to something that business partners can =
understand.
-- The role of facebook privacy settings, controll=
ing what gets shared with who, was noted
-- Chris has an app that will ask facebook for eve=
rything it can share...
--------------
AI -- Dedra will take a first cut at language differentiating social loa= 1 from campus loa 1
AI -- group -- the group should explore ways to express the difference b= etween social and enterprise level 1.
AI -- Nate to share url's for other LOA frameworks.