Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Link profiles across multiple platforms #83

Closed
timothyfcook opened this issue Sep 7, 2016 · 4 comments
Closed

Link profiles across multiple platforms #83

timothyfcook opened this issue Sep 7, 2016 · 4 comments

Comments

@timothyfcook
Copy link
Contributor

timothyfcook commented Sep 7, 2016

Badge Issuers may use multiple badge issuing platforms or wish to transition from one to another.

User Stories:

  1. As an issuer, I want to have all of my issued badges reference a single issuer profile so that I may use multiple badge-issuing applications or switch between platforms.
  2. As a consumer or recipient, I want to understand when multiple Badge Assertions are awarded by the same organization or individual, even if that issuer uses multiple platforms.
@1l2p
Copy link

1l2p commented Oct 1, 2016

I am not sure I fully understand what is being proposed here, but as much as possible issuer identity should be independent of issuer platform. However, aggregating badges that were issued by the same institution, with different institutional identities, seems to best be handled in the backpack/wallet rather than the badge itself.

@ottonomy
Copy link
Contributor

How about:
"sameAs": "https://other.net/profile/3"?

If that appears claimed in an endorsement you trust, you can associate them. Or if two profiles have a property verified by endorsements ypu trust, you can associate them.

For 1, just point the issuer property in a BadgeClass or Assertion to the same profile? Of course, you'll have to prove that it's ok that you made that claim. The second issuing platform and the eventual consumer of the badge will have to trust that the same entity triggered the publication. That's the root problem to solve (number 2). The "same domain" assumption you're otherwise relying on is far weaker than you would like.

Fully agree with @1l2p. The identity provider should be a wallet or wallet service that handles authenticating identity. Authenitcating identifiers is a different function and orthogonal problem.

ottonomy added a commit that referenced this issue Dec 31, 2016
…endorsement extension #73 #76 #79. (and in my opinion also #83 and #88, though platform support would be required)
@ottonomy
Copy link
Contributor

With #88, this is made possible via Endorsement in the 2.0 Recommendation.

@mgylling
Copy link
Contributor

mgylling commented Feb 1, 2017

Closing this issue, as it was resolved by the 2.0 Recommendation. This issue and all other issues resolved by 2.0 can be found via the 2.0 Release Candidate milestone and PR #99.

@mgylling mgylling closed this as completed Feb 1, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
No open projects
Development

No branches or pull requests

4 participants