Clarification on Signed Badges

[Excel]

Hello,

       In the case of signed badges, the public key stored in assertion.verify.url can unpack the JWS payload, signed by the issuers private key, and when the issuer hasn't revoked the badge. The format at baking would be like...

<encoded JWS header>.<encoded JWS payload>.<encoded JWS signature>

An Example is as below.

eyJhbGciOiJSUzI1NiJ9
.
eyJ1aWQiOiJhYmMtMTIzNCIsInJlY2lwaWVudCI6eyJ0eXBlIjoiZW1haWwiLCJoYXNoZWQiOnRydWUsInNhbHQiOiJkZWFkc2VhIiwiaWQiOiJzaGEyNTYkYzdlZjg2NDA1YmE3MWI4NWFjZDhlMmU5NTE2NmM0YjExMTQ0ODA4OWYyZTE1OTlmNDJmZTFiYmE0NmU4NjVjNSJ9LCJpbWFnZSI6Imh0dHBzOi8vZXhhbXBsZS5vcmcvYmV0aHMtcm9ib3QtYmFkZ2UucG5nIiwiZXZpZGVuY2UiOiJodHRwczovL2V4YW1wbGUub3JnL2JldGhzLXJvYm90LXdvcmsuaHRtbCIsImlzc3VlZE9uIjoxMzU5MjE3OTEwLCJiYWRnZSI6Imh0dHBzOi8vZXhhbXBsZS5vcmcvcm9ib3RpY3MtYmFkZ2UuanNvbiIsInZlcmlmeSI6eyJ0eXBlIjoic2lnbmVkIiwidXJsIjoiaHR0cHM6Ly9leGFtcGxlLm9yZy9wdWJsaWNLZXkucGVtIn19
.
Liv4CLviFH20_6RciUWf-jrUvMAecxT4KZ_gLHAeT_chrsCvBEE1uwgtwiarIs9acFfMi0FJzrGye6mhdHf3Kjv_6P7BsG3RPkYgK6-5i9uZv4QAIlvfNclWAoWUt4j0_Kip2ftzzWwc5old01nJRtudZHxo5eGosSPlztGRE9G_g_cTj32tz3fG92E2azPmbt7026G91rq80Mi-9c4bZm2EgrcwNBjO0p1mbKYXLIAAkOMuJZ_8S4Go8S0Sg3xC6ZCn03zWuXCP6bdY_jJx2BpmvqC3H55xWIU8p5c9RxI8YifPMmJq8ZQhjld0pl-L8kHolJx7KGfTjQSegANUPg


In the above case, If the entire payload is encoded

1. How will the other side know how to decode?
2. Only when we decode, we'll get the assertion in payload which directly has the public key URL link inside Assertion. When once we already have the Assertion what is the point in having the public key to unpack the already unpacked JWS payload. What I mean is public key should have been outside of Assertion to get the public key for unpacking the encoded Assertion. Please clarify how it works
3. What is the significance of Signature in the end of JWS and is used for what?

Regards,
Excel

[Nate Otto]

The payload can be base64decoded without use of the public key, but you're right to criticize the location of the public key in the signed assertion. My proposed solution, which I hope to address after finishing up a phase of work redrafting the Recipient class is to make the publicKey a property of the Issuer Profile, not the Assertion. You've uncovered one of the obvious weaknesses with linking in the Assertion. What do you think of this modification? 

There was an initial assumption dating from the first release of the signed badges spec, that each issuer would be an organization with their own domain name and their own badging application running on that domain. That has proven to be very far off the mark, and with the next release of the spec, it's a great time to fix it. The goal is by the end of the year to have the foundations of a distributed web of trust where we can trust which @ids correspond to issuers known to us, and what their public keys are. Build the foundation for issuers who are broadly trusted to rise above newcomers by amassing large numbers of endorsements.

Nate Otto

Director of Technology, Badge Alliance

badgealliance.org