Identity in the Academy

Identity in the Academy

Day/Session:Wednesday 3C

Convener:Phil Windley

Notes-taker(s): Nick Roy

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

One thing we could talk about is some of the plans for using verifiable credentials inside/outside BYU

BYU trying to create a system-wide profile - a web app, CAS at different levels in the system

System agent, BYU agent are agents in the ledger in the SSI system

BYU issue transcript to the ledger, student gives consent to share the transcript with the other schools in the system

Hard: How do we bootstrap a student with a credential?

Navigate to BYU webapp, go to CAS, redirects back to the browser, goes back to the webapp, webapp calls CAS to get attributes through SAML. Those attributes provide who the student is in the form of session data.

Can ask the student for consent to participate in the student profile, if they say yes, redirect them over to the profile web app. The CAS instances are federated, now can communicate the student information to the system. Can link credentials and ask the student if they want to share information with the system profile app. Then go to the system agent to start a process to create a wallet. The system agent can talk to the BYU agent and establish a pairwise DID relationship that is unique. Issue a credential to the student in the system profile app. Can assert info to the student, issue verifiable credential. Then BYU can issue things into the identity using a cryptographic proof.

What do the SAML attributes look like?

In the legacy system you have a credential table.

In the credential table, you can do crosswalks to other identities/credentials.

<I talked about research identity here>

SAML attributes would say here is how you can contact the BYU agent

Another SAML attribute would have that DID that comes over to express the identity

Legacy authN system on top of SSI DID

If Microsoft or some other system wants to participate, we don't want them to have to stand up CAS.

Don't know who the person is at a system level until they authenticate at their institution.

Early prototype

I talked about proxies, ORCID and attributes in SAML federation. Could use a person's digital wallet to bootstrap their scholarly identity, research identity, identity in the proxy, etc. Allow them to relink their account using their digital wallet.

Creating a fine-grained taxonomy of competencies to allow you to map course equivalency for things like prerequisites. Use a zero-knowledge proof to test if someone has gained the needed competency.

Working on how to create the schemas in a rich format. Until then, they can bootstrap this within the university system using the entire blob of shared person info.

Working on an edu API with Michael Berman from IMS Global.

University can write a public DID and claim definition to issue credentials for, say, the alumni part of the lifecycle.

Real benefit is not authentication, it's carrying information about the person - badging, etc.

Going to a wallet-based system, you don't have to make tons of API calls, and you get loose coupling back.

BYU presented at consensus NY using the CLR specification to present a digital diploma, using a mobile app.

Because Microsoft owns LinkedIn, they wanted someone to be able to go to LinkedIn to prove they have a degree.

Since then, they have created that link, so you can now do that in LinkedIn.