W3C home > Mailing lists > Public > public-credentials@w3.org > July 2015

Fwd: [ba-standard] Re: OBI ideas

From: Eric Korb <eric.korb@accreditrust.com>
Date: Wed, 29 Jul 2015 13:20:13 -0400
Message-ID: <CAMX+RnD7k+SV4qtSbKdxSmutprwFq95oJDPZ6Gfu8kST8bvXEA@mail.gmail.com>
To: Credentials Community Group <public-credentials@w3.org>
Cross posting.

---------- Forwarded message ----------
From: Nate Otto <nate@ottonomy.net>
Date: Wed, Jul 29, 2015 at 1:16 PM
Subject: [ba-standard] Re: OBI ideas


Thanks for posting, Attila. This kind of thinking is what we need as we
contemplate where to go from 1.1 to the next version (likely 2.0). Adding
the BA-standard mailing list to the discussion (you should join that one
too if you haven't already).

I'll reply with some recent thinking I've been doing along the same lines
when I get a chance in the next day or two.


*Nate Otto*
*Interim Director, Badge Alliance*
badgealliance.org

On Monday, July 27, 2015 at 1:24:00 PM UTC-7, Szabó Nagy Attila wrote:
>
> Dear DEVS and WG!
>
>
> After joining the discussion conference I was thinking about how to keep
> simplicity and keep the whole OBI up to date and I tried to get to the core
> and build it up from there. So the main idea was: what is absolutely
> essential, that should be kept? - and everything else should become an
> extension. So I came up with this idea:
>
> Assertion:
>   @context
>   type
>   id: uid or json-ld link
>   issued on
>   (extension.assertion
>     verify
>     evidence
>     expires
>   )
>
>   recipient:
>     identity
>     hashed
>     salt
>     (extension.recipient)
>
>   badgeclass:
>     @context
>     type
>     id: name OR json-ld link
>     description
>     image
>     creator.badgeclass - not issuer
>       @context
>       type
>       id: link to org website OR json-ld link
>       (extension.creator:
>         name
>         url - is this needed?
>         description
>         image
>         email
>         revocation list
>         nomination list***
>       )
>     (extension.badgeclass:
>       criteria
>       tags
>       alignment
>     )
>   issuer:
>     @context
>     type
>     id - can be creator.badgeclass or nominated
>     nominated:
>       @context
>       type
>       id: link to org website OR json-ld link
>       nominated_by: can be creator.badge or another nominated who is
> nominated to nominate :-) - the end link of the nomination chain should be
> cretator.badge
>       (extension.nominate:
>         name
>         url - is this needed?
>         description
>         image
>         email
>         revocation list
>         nomination list
>       )
>
> ***
> nomination list looks something like this:
> org: id or something - nominated to issue: boolean - nominated to
> nominate: boolean.
>
>
>
> So a very basic core assertion would look like this:
>
> Assertion:
>   @context
>   type
>   id: uid
>   issued on
>
>   recipient:
>     identity
>     hashed
>     salt
>
>   badgeclass:
>     @context
>     type
>     id: name
>     description
>     image
>     creator.badge - not issuer
>       @context
>       type
>       id: link to org website
>
>   issuer:
>     @context
>     type
>     id: - creator.badge
>
> this is only a draft... the main idea is that the core should be possible
> to be baked into the badge image and the badgecheck and badge should work
> even if there are no json files hosted.
> of course the quality of a badge like that it is not the highest one, but
> for some cases - or for many cases it should be enough for those who want
> to start working with badges at a very basic level.
>
> I don't know if this is possible, or if it makes sense. I hope I could
> contribute with the ideas.
>
> Thanks for taking it into account.
>
 --
You received this message because you are subscribed to the Google Groups
"BA Standard Working Group" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to ba-standard+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Received on Wednesday, 29 July 2015 17:21:06 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 July 2018 21:19:24 UTC