Skip to content

Identity management #55

Closed
Closed
Identity management#55
Labels
area/identityRelates to identitieskind/featureRelates to a new feature

Description

@MichaelMure
MichaelMure
opened on Oct 2, 2018

Currently, each Operation store the author independently. While it's easier and works well for now, there is some shortcoming:

  • no way to update an identity (update an email, update an avatar ...)
  • no easy way to recognize that two author are the same
  • data is stored multiple time (no that much of an issue with the git compression)
  • crypto signature & authorization scheme is hard to implement

So I've been thinking it could be changed for the following (rough idea):

  • identity (including a public key would be neat) is stored as a JSON in a git blob
  • this blob hash give the id for this identity
  • each time an identity is updated, a new blob is created with the new values and these blob are linked together in a chain of commit, the head being the last state.
  • in each operations, actor(s) are simply identified with the id.

Now, I'm not sure yet how these identities should be stored and distributed. a git ref for each identity ? Each required identity linked in the OperationPack git tree ? A master ref aggregating all known identities ?

Hopefully this would be the last of the backward-incompatible change in the data model

Activity

  1. MichaelMure
    added
    RFCRequest for comments
    Core
    on Oct 2, 2018

  2. MichaelMure commented on Feb 17, 2019

    @MichaelMure
    MichaelMure
    on Feb 17, 2019
    ContributorAuthor

    Here is the CLI UX I thought about, comments ?

    # Display current identity (any identity if <id> is specified)
git bug user [--time <time>] [<id>]

# Create a new identity
git bug user create

# Adopt an existing identity as your own
git bug user adopt <id>

# List identities
git bug user ls

# Display the current name (any identity if <id> is specified)
git bug user name [--time <time>] [<id>]

# Display the current email (any identity if <id> is specified)
git bug user email [--time <time>] [<id>]

# Display the current login (any identity if <id> is specified)
git bug user login [--time <time>] [<id>]

# Display the current avatarURL (any identity if <id> is specified)
git bug user avatarURL [--time <time>] [<id>]

# Set the current name
git bug user set name <name>

# Set the current email
git bug user set email <email>

# Set the current login
git bug user set login <login>

# Set the current avatarURL
git bug user set avatarURL <avatarURL>

# Display the current keys (any identity if <id> is specified)
git bug keys [--time <time>] [<id>]

# Manage keys (to be determined)
git bug keys import ...
git bug keys export ...
git bug keys add ...
git bug keys generate ...
git bug keys revoke ...

  3. MichaelMure commented on Mar 3, 2019

    @MichaelMure
    MichaelMure
    on Mar 3, 2019
    ContributorAuthor

    #89 has been merged with the bulk of the changes, but there is a few things left to iron properly before a release can happen.

  4. MichaelMure commented on Apr 2, 2019

    @MichaelMure
    MichaelMure
    on Apr 2, 2019
    ContributorAuthor

    As of now, this is pretty much done. All the core features are there, tested and working.

    What is left is the few command line tool to get/set particular identity fields:

    # Display the current name (any identity if <id> is specified)
git bug user name [--time <time>] [<id>]

# Display the current email (any identity if <id> is specified)
git bug user email [--time <time>] [<id>]

# Display the current login (any identity if <id> is specified)
git bug user login [--time <time>] [<id>]

# Display the current avatarURL (any identity if <id> is specified)
git bug user avatarURL [--time <time>] [<id>]

# Set the current name
git bug user set name <name>

# Set the current email
git bug user set email <email>

# Set the current login
git bug user set login <login>

# Set the current avatarURL
git bug user set avatarURL <avatarURL>

  5. edef1c commented on Mar 22, 2020

    @edef1c
    edef1c
    on Mar 22, 2020

    Is there an intention to allow adopting a bridge identity that has otherwise not interacted with the particular repository? This comment is partially a way of allowing me to adopt my GitHub identity for this repo, because I'm not sure if I can merge the two if I use the exporter. Is that what git bug user set login would do?

  6. hoijui commented on Jun 2, 2020

    @hoijui
    hoijui
    on Jun 2, 2020
    Contributor

    in a fully distributed git world, this is a more important and difficult question...
    how do we prevent identity theft?
    should measures preventing that be the default or optional?
    would each user decide whether they want to use a secure way of identity management, or each repo, or a mix/combination of the two?
    is avatar-URL really enough, or should the avatar image rather (optionally) be stored in the repo?
    ...

    I feel like such decisions are really hard, and in the end will always have to be changed later on, as one did not think of everything from the start, so the most important thing in my eyes, is to use versioning, and in such a way that really everything can be changed, if deemed necessary, or even just beneficial.

    what is the login used for?

  7. hoijui commented on Jun 2, 2020

    @hoijui
    hoijui
    on Jun 2, 2020
    Contributor

    EDIT: Better read a short article about DIDs,
    then the official standard linked to below. ;-)

    I just stumbled over W3Cs Decentralized Identifiers (DIDs):

    Decentralized identifiers (DIDs) are a new type of identifier to provide verifiable, decentralized digital identity. These new identifiers are designed to enable the controller of a DID to prove control over it and to be implemented independently of any centralized registry, identity provider, or certificate authority. DIDs are URLs that relate a DID subject to a DID document allowing trustable interactions with that subject.

    it sounds quite optimal so far. It is still in the making though (as of mid 2020)!

  8. MichaelMure commented on Jun 2, 2020

    @MichaelMure
    MichaelMure
    on Jun 2, 2020
    ContributorAuthor

    in a fully distributed git world, this is a more important and difficult question...
    how do we prevent identity theft?

    By having crypto keys. See #130

    should measures preventing that be the default or optional?
    would each user decide whether they want to use a secure way of identity management, or each repo, or a mix/combination of the two?

    My view is that as a general UX principle git-bug should have a default that is 1) functional with little to no configuration 2) address a wide range of use cases and 3) allow to add additional constraint to restrict to a more specific use case.

    For this problem in particular, I think the best way would be:

    • default would have no crypto keys. Identity theft is possible but that's not a problem in a lot of real life scenario (you would first need to have git write access). Identities are marked as "unprotected".
    • it's possible for each user to opt-in and protect their identity by adding keys
    • when a project config exist, add a settings to enforce having keys for each identities

    is avatar-URL really enough, or should the avatar image rather (optionally) be stored in the repo?

    It's very crude at the moment. Yes, it should be improved and stored in the repo if possible.

    I feel like such decisions are really hard, and in the end will always have to be changed later on, as one did not think of everything from the start, so the most important thing in my eyes, is to use versioning, and in such a way that really everything can be changed, if deemed necessary, or even just beneficial.

    If by versioning you mean data model versioning, it's already there. Every piece of data stored in git has this version number. It's especially important because those are immutable. It's not really used though at the moment.

    what is the login used for?

    An identity's login is optional and is only meant to store the login used on the bridge that created this identity. It's just informational, to display in the UI both full name and login when available. This exist in part because Github mainly display the login (so you know people by that name) so if you don't have the login in git-bug's UI you can see names you have never seen before even though you know the people.

  9. MichaelMure commented on Jun 2, 2020

    @MichaelMure
    MichaelMure
    on Jun 2, 2020
    ContributorAuthor

    Not super knowledgeable about DID but AFAIK they don't work offline ?

    Note that identities in git-bug is just an interface (https://github.com/MichaelMure/git-bug/blob/master/identity/interface.go). It could be replaced by another implementation someday if the need arise.

  10. hoijui commented on Jun 2, 2020

    @hoijui
    hoijui
    on Jun 2, 2020
    Contributor

    Not super knowledgeable about DID but AFAIK they don't work offline ?

    I concluded that same thing just now before coming back here. :-)
    basically, DID relies on the unique, singular state of global-state block-chains like Bitcoin and Etherium. In theory, one could fetch stuff once and keep it offline available, but even then I would not deem it a fitting technology, as it relies on the global unique state/the whole internet, and is thus not itsself P2P to the core, as is something like IPFS, git, or git-bug.
    It might make sense though, to ditch the blockchian part (basically, the DID address/URL and the way of how to get to the DID document), but use the DID document part of the standard; an example.
    This is mostly concerned about authentication and communication. I am not sure if it allows having additional, custom key-value pairs in there, like login. At some point the specification said, that only the DID IRI might be used, which would suggest that it would not be valid. then again, git-bug would not be bound to adhere to that, apart from theoretically having problems with DID document parsing libraries.

    Just brainstorming here; not that I think I know how it should be.

    Note that identities in git-bug is just an interface (https://github.com/MichaelMure/git-bug/blob/master/identity/interface.go). It could be replaced by another implementation someday if the need arise.

    perfect, thanks! :-)

  11. MichaelMure commented on Nov 20, 2022

    @MichaelMure
    MichaelMure
    on Nov 20, 2022
    ContributorAuthor

    Closing as it's either done, outdated or non-actionable.

  12. MichaelMure
    closed this as completedon Nov 20, 2022
  13. sudoforge
    added
    area/identityRelates to identities
    kind/featureRelates to a new feature
    and removed
    RFCRequest for comments
    Core
    on Aug 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area/identityRelates to identitieskind/featureRelates to a new feature

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions