Disclosure of Identity Attributes

PubHubs lets paticipants be pseudonymous when appropriate, and also includes mechanisms for participants to reveal their identity when that is required.

Disclosure of Identity Attributes is the ability for a moderator to ask a someone to disclose an attribute of their real identity.

When a person signs in to PubHubs hub through the Yivi verified credentials system, initially they are allocated a pseudonymous user identifier, for example @123-321. From this pseudonym, not even an operator or moderator of the hub can discover the user's real identity.

A moderator may wish to ask a user to confirm their real identity, to some degree. Through Yivi it is possible to ask a user to reveal a cryptographic proof 1 of one or more of their identity attributes. Some common attributes are one's real name, physical address, or email address. An attribute could also be something like "age is at least 18 years".

The initial implementation of the feature is described below, followed by ideas for further work.

Background

From the paper PubHubs identity management (pdf) ↗:

To access a secure room -> all participants must disclose certain attributes

and

A variety of warning and sanction mechanisms...

  • yellow cards
  • delayed posting for certain pseudonyms
  • content scanning before posting
  • sign messages with a selection of their attributes
  • identity disclosure (to the moderator, or to the room)
  • temporary ban
  • ban from room
  • ban from hub
  • ban from PubHubs Central

Identity disclosure for accessing a secure room is already implemented.

Here we implement identity disclosure on request.

Proposed Flow for Identity Disclosure

"Moderator" is someone who has permission to enact this work flow; "person" (rather than "user") is the participant being asked to identify themselves.

  1. Person:
  • joins a hub room
  • receives read+write permission (optional)
  • and reads and/or writes (optional)
  1. Moderator:
  • requests Person disclose a specific attribute (or set or choice of attributes) to the moderator or to the room
  • restricts Person's read+write permission, temporarily (optional)
  • and indicates to other participants that Person is (temporarily) "away" (optional)
  1. Person:
  • discusses with the moderator -- and then may comply/refuse/ignore
  • complies by providing the requested attribute(s)
  • refuses
  • ignores

The possible outcomes:

  • Person discusses first -- private discussion with this moderator
  • Person ignores -- nothing further happens in this flow
  • Person refuses -- nothing further happens in this flow; moderator may adjust permissions or update the "away" status
  • Person complies -- moderator may wish to check the response and then reinstate permissions

Considerations for promoting good behaviour

Assume, in the design decisions, that the outcome will be good agreement. For example, if the user interface design shows any kind of indication to other participants about the Person being temporarily unable to participate, it should avoid showing a label that suggests Person is being sanctioned or is suspected to be behaving badly. Instead, use only a label that is also used in innocent situations, such as "away".

Disclosure Flow Implemented

A moderator asks someone to disclose an attribute of their real identity. The recipient provides the requested attribute, using Yivi to attach a cryptographic proof.

The disclosure UI can be seen in an interactive UI prototype . (Press the ▶ "play" button to start interactive mode.)

  1. the moderator is concerned about a user (pseudonym 'bad-apple3'), and starts the disclosure request

    1a

  2. moderator chooses: a user, a message, a set of attributes

    1b

  3. on submitting the form, a private room with the recipient is created or opened, and a request message is sent into that room

    1c

  4. a Yivi signing session is started in the recipient's view (in this early demo screen-shot, it appeared in the moderator's view)

    1d 1d2

  5. the recipient uses Yivi to provide the requested attributes, with which Yivi signs a (pre-filled) reply message

    1e

  6. the reply, signed with the requested attributes, is received by the moderator in the private room

    1f

Initiate from the Room Message View

There is also an alternative way for the moderator to initiate the process: by clicking an action button next to any message that the person sent in a hub room. The user who sent that message is then pre-populated in the initial dialogue.

Improvement Ideas

This feature would benefit from some user experience improvements, both on the moderator's side and on the recipient's side.

Some initial ideas about improvements to the flow:

  • Alternative ways to initiate the process, such as a context-menu item on clicking on the user's avatar or pseudonym.

  • The recipient user should receive a more gentle notification than suddenly seeing a pop-up dialogue of any kind. Perhaps a notification consistent with other notifications, though perhaps indicating a greater "urgency", from which they can then access the full details of the request when they are ready.

  • An overview or "dashboard" for the moderators to keep track of such requests and responses.

  • A way for moderators or administrators to set up their preferred default disclosure request message(s) and attribute(s), in advance, so the moderator does not have to think about these things when under the pressure of resolving an incident.

Project Tracking

See Also

  1. A proof that such an attribute has been attested by some mutually trusted authority. ↩