[Openid-specs-ab] Open Badges / JSON-LD Signatures

Fri Jul 13 17:21:17 UTC 2018

Nat,

I looked at this quite extensively a while back. There are a few SaaS 
providers that are issuing Open Badges, like Cred.ly, Badgr.io. 
Salesforce is actually the largest issuer of badges: 
https://trailhead.salesforce.com/

The JSON-LD signature stuff is draft, and it doesn't seem like it's 
going to ever go final. Manu Sporny would be a good one to ask about 
that.

Perhaps an alternative to signing the JSON-LD object is to write it to a 
blockchain, and reference it via DID. Also, this community has some 
experience signing JSON objects...

I don't think we need signing to make badges useful. The badge is a type 
of JSON assertion. It includes:

1. subject (recipient)
2. issuer
3. badge info (what type of badge, how do you get it, etc.)

Some interesting questions arise about this kind of assertion: like how 
do you know the presenter of the badge is the same person as the 
recipient? Who defines badges? How do organizations issue them? How is 
badge interoperability achieved?

The spec is pretty weak on identity--the recipient is identified by an 
email address in the assertion. Could the recipient field be an id_token 
instead? Or perhaps a signed Userinfo JWT? Or a DID?

I'm very interested in OpenBadges as a kind of "pushed claim token" as 
defined by UMA. An UMA client can push an identity assertion like an 
id_token or SAML assertion while obtaining a token at the UMA token 
endpoint (i.e. RPT endpoint). But pushing an Open Badge (or a DID 
reference to a badge) also could provide useful information to determine 
if a client should be given access to an UMA protected API. For example, 
if you're trying to call a law enforcement API, maybe you need to 
provide a badge that you're a police officer.

Gluu implemented an Open Badge API server as part of a pilot for DHS, 
called ERASMUS. Attached is a screenshot from that project. Badges need 
to be defined, and a workflow for issuance also needs to be defined. In 
the ERASMUS pilot, we proposed that an organization which is a member of 
a federation define badges, and that the badge publishing infrastructure 
is hosted by the federation. Unfortunately, funding for this pilot was 
cancelled (it was deemed not innovative enough), and no further progress 
has been made. The github for the ERASMUS project is here:
  https://github.com/GluuFederation/erasmus

Net-net, I think this is a really interesting topic. I was a speaker at 
the Badge Summit in 2017 (https://badgesummit.weebly.com/), and my 
appraisal of the community is that they are quite unaware of trends in 
federated identity. In my talk, I made the case that badges with a 
stronger identity backing could increase the number of organizations 
that *consume* badges. One of the issues facing their industry is that 
there are more issuers of badges then consumers.  Perhaps that's because 
specifying the recipient only by email inhibits the usefulness.

- Mike

------------------------
Michael Schwartz
Gluu
Founder / CEO
mike at gluu.org
https://www.linkedin.com/in/nynymike/

On 2018-07-12 07:00, openid-specs-ab-request at lists.openid.net wrote:
> Send Openid-specs-ab mailing list submissions to
> 	openid-specs-ab at lists.openid.net
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://lists.openid.net/mailman/listinfo/openid-specs-ab
> or, via email, send a message with subject or body 'help' to
> 	openid-specs-ab-request at lists.openid.net
> 
> You can reach the person managing the list at
> 	openid-specs-ab-owner at lists.openid.net
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Openid-specs-ab digest..."
> 
> 
> Today's Topics:
> 
>    1. Re: ITP2 response draft (Filip Skokan)
>    2. Open Badges / JSON-LD Signatures (n-sakimura)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Wed, 11 Jul 2018 21:45:36 +0200
> From: Filip Skokan <panva.ip at gmail.com>
> To: vittorio.bertocci at auth0.com
> Cc: "openid-specs-ab at lists.openid.net Ab"
> 	<openid-specs-ab at lists.openid.net>
> Subject: Re: [Openid-specs-ab] ITP2 response draft
> Message-ID:
> 	<CALAqi__ewZ+AG7mBH9L7O0kiiLv4-Nbt1D4uhU+J2w8ks5Cdig at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
> 
> Dear all,
> 
> We've had some good feedback so far, thank you so much. Since there 
> wasn't
> much more coming the past few days I'm going to go ahead and finalize 
> the
> response's language based on the feedback that we got so far tomorrow.
> 
> If you didn't manage to review yet, I kindly ask that you do so really 
> soon.
> 
> Lastly, if your company or you as individuals wishes to be added as 
> signees
> please let me know (email me, email the group or add yourself in the 
> draft,
> either way works), the more the merrier.
> 
> Kind Regards,
> *Filip Skokan*
> 
> 
> On Tue, Jul 3, 2018 at 11:14 PM Vittorio Bertocci <
> vittorio.bertocci at auth0.com> wrote:
> 
>> Dear all,
>> 
>> thanks for participating in the ITP2 impact discussion last week at
>> Identiverse. It was great to see so many different vendors come 
>> together
>> to brainstorm how to handle the situation as an industry.
>> 
>> As agreed, I took the action to write down a summary of the possible
>> approaches we discussed - you can find a fully editable draft at
>> 
>> https://docs.google.com/document/d/16Tg7k03RYHXiyBMAFAu0NK91ZvvjvmzbqWi5FFvK388/edit?usp=sharing
>> .
>> 
>> Please take a look at the draft, and comment & edit as you see fit. 
>> Once
>> we converge to a text that works for everyone, we can discuss how we
>> want to engage Apple.
>> 
>> I am about to get some time off: my colleague Filip Skokan, whom many 
>> of
>> you already know for his work on OIDC compliance testing, helped with
>> the document draft and will be the Auth0 representative in the 
>> discussion.
>> 
>> Thanks!
>> 
>> Cheers,
>> 
>> V.
>> 
>> 
>> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20180711/04e4a142/attachment-0001.html>
> 
> ------------------------------
> 
> Message: 2
> Date: Thu, 12 Jul 2018 03:57:28 +0000
> From: n-sakimura <n-sakimura at nri.co.jp>
> To: "openid-specs-ab at lists.openid.net"
> 	<openid-specs-ab at lists.openid.net>
> Subject: [Openid-specs-ab] Open Badges / JSON-LD Signatures
> Message-ID:
> 	<TY2PR01MB2297463B91AE2D9AB9070500F9590 at TY2PR01MB2297.jpnprd01.prod.outlook.com>
> 
> Content-Type: text/plain; charset="iso-2022-jp"
> 
> Hi
> 
> Just came across to Open Badges, backed by Mozilla?
> 
> 
>   *   https://openbadges.org/
>   *   
> https://www.imsglobal.org/sites/default/files/Badges/OBv2p0/index.html
> 
> It seems to be adopted by over 3000 organization.
> 
> It seems to use JSON-LD Signatures, which does some canonicalization.
> 
> Anybody with some knowledge / experience / issues around it?
> 
> Nat Sakimura <n-sakimura at nri.co.jp<mailto:n-sakimura at nri.co.jp>>
> 
> PLEASE READ :This e-mail is confidential and intended for the named
> recipient only. If you are not an intended recipient, please notify
> the sender and delete this e-mail.
> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20180712/fe2583c0/attachment-0001.html>
> 
> ------------------------------
> 
> Subject: Digest Footer
> 
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
> 
> 
> ------------------------------
> 
> End of Openid-specs-ab Digest, Vol 389, Issue 3
> ***********************************************
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fides-federation.png
Type: image/png
Size: 44483 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20180713/0edc74fc/attachment.png>