Difference between revisions of "Identity in the Academy"

From IIW
Jump to: navigation, search
(Created page with "'''Identity in the Academy ''' '''Day/Session:'''Wednesday 3C '''Convener:'''Phil Windley '''Notes-taker(s):''' Nick Roy '''Discussion notes, key understandings, ou...")
 
 
Line 39: Line 39:
 
In the credential table, you can do crosswalks to other identities/credentials.  
 
In the credential table, you can do crosswalks to other identities/credentials.  
  
<I talked about research identity here>  
+
<nowiki><I talked about research identity here> </nowiki>
  
 
SAML attributes would say here is how you can contact the BYU agent  
 
SAML attributes would say here is how you can contact the BYU agent  
Line 84: Line 84:
  
 
Since then, they have created that link, so you can now do that in LinkedIn.
 
Since then, they have created that link, so you can now do that in LinkedIn.
 +
 +
[[file:27W3C.jpg]]

Latest revision as of 22:53, 8 November 2018

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.

27W3C.jpg