Date: Thu, 28 Mar 2024 15:44:13 +0000 (UTC)
Message-ID: <1157574894.6593.1711640653829@ip-10-10-7-29.ec2.internal>
Subject: Exported From Confluence
MIME-Version: 1.0
Content-Type: multipart/related;
boundary="----=_Part_6592_816721509.1711640653828"
------=_Part_6592_816721509.1711640653828
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Content-Location: file:///C:/exported.html
Proposed Charter: External Identities =
Working Group
Name
External Identities Working Group
TBD
Group Leader (Chair)
Paul Caskey (UT System) <pcaskey@utsystem.edu>
Miss=
ion/Goals
The mission of the External Identities Working Group is to move the comm=
unity of knowledge towards the goal of making external identities useful an=
d sufficiently trusted in a variety of campus-based use cases. This group i=
s focused on the use of external identities by individuals, rather than an =
enterprise using an external identity provider as their enterprise IdP.
Specific goals for the External Identities Working Group include:
- Exploring/developing deployment models for using external identities in=
a variety of risk profiles
- Identifying and examining the technical components that are needed to m=
ake external identities useful across a broad array of services
- Exploring the notion of account linking between a campus-issued account=
and an external account
- Understanding the differences between external identities and local ide=
ntities
Members=
hip
Membership in the Working Group is open to all interested parties. Membe=
rs join the Working Group by subscribing to the mailing list, participating=
in the phone calls, and otherwise actively engaging in the work of the gro=
up.
The chair of the Working Group is appointed by the InCommon TAC and is r=
esponsible for keeping the TAC informed regarding Working Group status.
Deliv=
erables
- Update (i.e., make current) the set of use cases previously developed b=
y the Social Identities Working Group. This should include use cases for th=
e following situations:=20
- Social account linked to a campus-issued account
- Social identity used by a non-community member
- Develop a set of criteria for selecting external providers in a variety=
of usage scenarios. Ensure that both social providers (e.g., Google, Faceb=
ook, Twitter) and non-social providers (e.g., Microsoft, PayPal, VeriSign) =
are included.
- Identify and document properties of external accounts that would be of =
interest to web application owners and other relying parties. This should i=
nclude both a) how the account is managed for authentication purposes, and =
b) attributes asserted by the account provider.
- Define and document how a gateway would represent the properties of an =
external account to an application.
- Contrast a central gateway with a local gateway. List the advantages an=
d disadvantages of each deployment model.
- Provide application owners with recommendations regarding risk profiles=
when using external identities. (These profiles need not be based on the t=
raditional 800-63 categories.) Describe various approaches to risk manageme=
nt.
- Document various approaches to account linking:=20
- Accounts can be linked either centrally (in a campus Person Registry, a=
nd visible via the campus IDP), or at a specific SP (application).
- Linking a campus account to a known external account, and linking an ex=
ternal account to an existing campus-issued account, where both accounts ar=
e used by the same person.
- Identify the properties that an external account must/should possess th=
at would affect its use.
- Using an external authentication provider to authenticate to a campus-b=
ased service.
- Identify ways that campus-owned attributes could be asserted following =
authentication with an external account (e.g., group memberships)
- Produce a set of longer-lived recommendations for practitioners, roughl=
y comparable to the NMI-DIR documents (e.g., papers, not just wiki pages).<=
/li>
Potential Deliverables Considered to be Out of Scope for this Ph=
ase
- This WG will be looking at the use of personal external accounts; it wi=
ll NOT be looking at situations where an enterprise is using a social provi=
der as their IDP, for access to enterprise apps outside of google.
- Technical requirements for Interop/deployment profile for OpenID Connec=
t (OIDC)
- Recommendations on approaches for elevating an external account authent=
ication event to LoA 2.
- Identify and document pro's and con's of having students continue to us=
e their social account to access campus business systems during their stude=
nt days. Identify an interim step toward this milestone.
Ex=
pected End Date
The working group is expected to complete all deliverables by Dec 31, 20=
14.
=
Required Resources
- wiki =
space
- phone line for conference calls: usual Internet2 conference call line=
li>
- incommon.org group email list socialidentity@internet2.edu
Te=
leconferences
=
Reference Material
- FICAM Relying Party Guidance for External Credentials
- OASIS WOrking Group on Trust Elevation
------=_Part_6592_816721509.1711640653828--