What is a Backpack?

[andrewhayward]

At some point soon we're going to need to define what makes a backpack. I'm sure @stenington knows a lot more about this than I do, but I'll make a start.

Right now, our backpack boils down to three things:

• Users
• Badges
• Collections

Obviously users and badges are first-order entities (duh), but do we want to specify collections at the same level? My gut feeling is yes, but would be good to get other people's thoughts on the matter.

So, from a Open Badges Backpack (OBb) specification point of view, this might be considered a reasonable start (RFC 2119 yadda yadda):

• An OBb must have "user accounts" (loosely defined)
• An OBb must allow users to add badges
• An OBb may allow users to make specific badges "public"
• An OBb should allow users to create collections of badges
• An OBb may allow users to make specific collections "public"

"Public" here depends on context, and doesn't necessarily mean 'available to the whole world'. Within a school, for example, making your badge "public" may well still restrict it to people within the confines of the school network.

Further to these basic requirements, we probably also want to go a bit further (to cover stuff like federation, @brianloveswords?), and say that an OBb must have a way of programmatically interfacing with data (an API):

• An OBb API may allow a client to create, delete and update users
• An OBb API must allow a client to add a badge for a user
• An OBb API should allow a client to delete a badge for a user
• An OBb API should allow a client to retrieve a user's badges
• An OBb API may allow a client to make a user's badge public (or not)
• An OBb API should allow a client to create, delete and update a collection for a user
• An OBb API should allow a client to retrieve a user's collections
• An OBb API should allow a client to add/remove a badge to/from a user's collection
• An OBb API may allow a client to make a user's collection public (or not)

Of course, all of these actions should (must?) be restricted by permissions of varying levels, yet to be discussed. The only required point here is the ability to push badges to a backpack, meaning a full-blown API is not actually necessary for standard compliance.

Anyway, thoughts?

[xmatthewx]

This all looks very clear and sensible. Nice work.

I'm wondering -- should this define a one-to-one relationship between the earner and backpack? Or is it better left open? Edge cases:

• teams mastering group skills
• organizations demonstrating compliance
• parents retaining badges on behalf of their potty trained toddlers

[threeqube]

a one-to-one relationship between the earner and backpack?

@brianloveswords mentioned today possibility of having say an openbadges team backpack. This might be the future though.

[andrewhayward]

It's been brought up elsewhere the potential for collections to behave much like backpacks in their own right, allowing a user to point a website or other client to a collection instead of their entire backpack to limit the scope of what they might be able to see.

My initial thought was that it would make sense to tie backpacks to users, but not collections. However, there's really no reason for this, particularly if we're treating collections as sub-backpacks. Collections would just be backpacks in their own right, that happen to have a parent backpack. Badges could exist in multiple backpacks, and by appearing in one they would (could?) by definition appear in any parent backpacks. So ultimately I think it just comes down to permissions, and there's no need to limit anything inherently to one user.

That said, this is more of an implementation detail than a specification issue, and there's no reason why someone else making a backpack would need to allow for this scenario. I like the idea, and I think we should go with it, but I don't think we should be enforcing our own technical design decisions via the spec.

[iamjessklein]

@andrewhayward - agree with all of your statements her.

Re: collections - We have often talked about collection display (even a bit in issue #5 ) in a way that communicates to a badge viewer - curated pieces of information, so that it is easier to digest and perhaps even so that viewer might not have to learn what a backpack is, and orient themselves every time they return to this information.

I have to confess, sometimes I get confused by what we mean when we talk about a "backpack." When I sit down to think about future applications or mockups - I wonder to myself - what parts of this are in fact, technically a backpack? Look at this future - thinking one:

Is this a backpack embedded within a dashboard? Or is it something else completely? With the definition of users + badges + collections - the mockup includes a backpack, as well as some level of analysis and/or display tools. Would those be scoped out separately from the Backpack?

[stenington]

I stumble over the question @iamjessklein raises above, because I think there are two senses of the word "backpack", and I don't know which we're defining. Take real backpacks, for example: we could say "it's a backpack if you can put stuff in it and carry it around", but then briefcases and plastic sacks are also technically backpacks by our definition. Or we can say "well you should be able to carry things around, it should have two straps, zippers, pockets, etc." and we get closer to something that we all recognize as a backpack, but perhaps at the expense of limiting some interesting possibilities.

The should/may/must distinction does help alleviate that, and I think @andrewhayward has used them fairly judiciously. I'm not sure user accounts are a must, although I also think 99% of backpacks would want to have them. Otherwise you just have a single pile of badges.

I'm not entirely sure collections fall under should, either. I think you could make some fairly effective backpacks, like the example above that geolocates your badges for you, without providing any capability to group them. But again, it's easy to see that many backpacks would want to allow grouping for more like a resume/portfolio type display.

[kayaelle]

This is a great discussion.

The idea of having a backpack be storage and validator of single badges but collections as their own backpacks is appealing. I can envision backpacks wanting to define what a collection could be - it could be user defined (as it is now), could be defined by data - tags, issuers, additional metadata in the assertion. It's certainly helpful to use the api to display collection(s), it's also in some instances an extra step.

Must a backpack validate assertion requirements identically? For one example, may some backpacks require evidence? What is the definition of backpack data standards compliance? Is it as the assertion is defined currently?

Should a backpack store binary files or be able to read binary files and determine its own file storage?

How loosely should user accounts be defined? Would it be better to define some user accounts specifics such as email, OAuth, twitter, github... Having a little trouble wrapping my head around not requiring user accounts...

The question that @jess & @stenington mention is a good one - is the OBb simply (not meaning necessarily simple) storage, data and api? and which parts of that are musts? And then is there a "best example" backpack that contains collections, curation, etc...

What are thoughts on defining COPPA compliant backpacks? How about in relation to international youth who don't have the same compliancy issues?

[timothyfcook]

Moving to archive.