Roadmap

ID-Vault follows the concept of continuous beta. That means that features will be added whenever we are confident enough that they are ready enough for the world instead of a fixed release schedule. There are always several features under development that have not yet been released for the wider public.

If you want early access so you can use one of those features you can join the beta program for that feature. You can do so by sending us a message explaining why you want to join the beta program and how you want to use that specific feature. This way you will be able to use the feature early and provide us with specific feedback

The following list of features is presented as such, it doesn't aim to be comprehensive and are that none of these features are guaranteed to make it to production.


Notifications

The notification service allows organizations to stay “in touch” with an user's data.The notification service notifies the organisation when when a users data changes within a dataset(claim) to which the organisation has a scope. For security reasons the notification doesn’t actually contain the information that was changed, it merely points out that the claim was changed.

Notifications can be simply activated by providing a notification endpoint on your applications configuration. A POST containing a JSON message will be sent to that endpoint every time a claim is changed, to validify the post as originating from ID-Vault your applications state property will be added as a query parameter.

The message itself will contain the authorization token id (as an URI), and an array of the changed sopes allowing your application to make a precise call to get only the claims that have actually changed.


            {
                “authorization_token”:”https://id-vault.com/oauth/tokeninfo/uuid”,
                “scopes”:[“schema.person.adress”]
            }
        

You can view the notification logs of your application from the dashboard for debugging purposes. Keep in mind that making a call to the authorization token to get and compare the changed data will show up in the users logs and statistics. As such it is good practice to ONLY evaluate the users claim if this is essential to your primary process.

Required Scope: notification


Dossiers

A dossier is a data collection that isn’t part of the ID-Vault data set but is dependent on data that is part of the ID-Vault dataset, a good example of this would be an personnel file. Tough the file itself is part of an external HR system, it legally requires data that is part of a wallet (in this case social security numbers and contact details). Since this information is required by law users are unable to simply “delete” data that is part of a dossier. In fact dossiers are the only way a user can be blocked from simply deleting there data (do keep in mind that a user can still object to a dossier and get it removed by ID-Vault).

As such dossier are a rather heavy thing to use and come with there own limitations, as with all options that infringe on the users right a special scope has to be granted by the user ‘dosier’, additionally a user needs a way to access there dossier to be able to see what you actually have on them, this is done by providing a specific Single Sign On url (read more about single sign on functionality here). You also need to provide a name and description that are meaningful to the user, the actual scopes for which this dossier is blocking, a GDPR based goal for the dossier and an expiry date. All dossiers MUST have an expiry date the MAY NOT be more than 10 years in the future. Lastly the users authentication token is used to identify a user.

Actually creating a dossier is rather easy, just post it to https://id-vault.com/api/dossier (and don’t forget to add the user authorization token in the authentication header)

        
            {
                “name”:”Personel file at conduction”,
                “description”:”For your personal file at conduction we are legaly required to maintain your data for tax purposes”,
                “sso”:”{ your single sign on url}”,
                “scopes”:”schema.person.adress”,
                “goal”:”legal”,
                “expiryDate”:”legal”
            }
        
    

The dossier can then be altered or deleted by the application at the dossier specific endpoint https://id-vault.com/api/dossier/{uuid}, keep in mind that do no user permissions is required for that you can only create, update or destroy dossier while you hold the “dossier” scope.


Contract (and signing)

Contracts represent an ongoing or proposed legal commitment between one or more persons (represented by users)

A nice little sub feature of contracts is the signing of contract’s, that actually included in the contract. Basically there are two ways of offering a contract, either you add an already signed contract to a users wallet (in which case the signed property should be true) or you are requesting a user to sign a contract (in which case the signed property should be false) the later will trigger a signing procedure by the user.

It is also possible to allow users to terminate contract trough id vault, in that case the contract MAY BE with a “noticePeriod” property, stating the period that the contract runs after a termination request by the user. If a contract dosn’t have a “noticePeriod” it MUST have an “expiryDate”.

There are actually two ways of setting up contracts the first is for a single given user to wich you hold an authorization token AND have the contrac scope.

In that case ust post it to https://id-vault.com/api/contract (and don’t forget to add the user authorization token in the authentication header).

This is the ONLY way you can post already signed contracts.

        
            {
                “name”:”Phone Subscription”,
                “description”:”Your subscription at ConduCom”,
                “singed”:”false”,
                “expiryDate”:”legal”
            }
        
    

The second way allows you to add multiple signees to a contract,
Contracts by there nature cant be a altered or deleted by the application, they can however be viewed https://id-vault.com/api/contract/{uuid}, keep in mind that do no user permissions is required for that you can only create, update or destroy dossier while you hold the “contract” scope.


Single Sign On

To be honest, setting up single sign on is super easy, once you have setup OAUTH. Basically you just skip the first part of the OAuth implementation and set up an endpoint on which a user land (users will be forwarded form there ID-Vault SSO dashboard) , the user will again be provided with the code and state parameters when they hit your endpoint. Do this time the state will be a key provided by you during setup.

You can than use the code to acquire an access token normally and use that acces token to obtain user info and handle the login normally. Be aware that you need the single_sign_on scope for the user, this does mean that the user will need have to have authorized your application in the past (which implies that a regular login/registration has taken place in the past).


Mailing and Phone lists

By GDPR user need to consent to being mailed or called for commercial purposes, do most mailing tool nowdays include both this and an “opt-out” option it can be hard for users to keep track of where they have subscribed to.

First you need to create a list, this is as simple a posting a name and description to https://id-vault.com/api/send_list (keep in mind that in this cause you will need to authenticate as an application instead of as a user)

        
            {
                “name”:”My mailing list”,
                “description”:”For my awsome weekly mailing”,
                “mail”:true,
                “phone”:false,
                “clientSecret”:”{the client secret for your application}”
            }
        
    

Actually adding a user is then done by post to https://id-vault.com/api/send_list/{send_list uuid} no body is required (and don’t forget to add the user authorization token in the authentication header)

Alternatively you can add users to a mailing list in on a per email or phone basis, this feature is mainly mend for the “join mailing list” box commonly found on site. It requires you to forward an user to https://id-vault.com/send_list/{send_list uuid} the user will then be prompted to join you mailing list (and if he/she isn’t jet logged in login or create an account in order to manage their mailing preferences). You can include both email als phonenumber as a query property.

This allows you to either make a simple join mailing list link

        <a href=”https://id-vault.com/send_list/{send_list uuid}">Join our mailing list</a>'
    

or a slightly more elaborate join mailing list form.

        
            <form action=”https://id-vault.com/send_list/{send_list uuid}”>
                <input type=”email” name=”email” id=”email” placeholder=”Your email addres”>
                <input type=”button” value="Join our mailing list">
            </form>
        
    

As a next stap you can then actually send you mailing and/or text messages trough ID-Vault, by posting it to https://id-vault.com/api/send_list/{uuid}/send. Additional cost will apply

        
            {
                “title”:”My awsome mailing”,
                “message”:”My mailing”,
                “text”:”My mailing”,
                “html”:”<p>HTML content of the mail</p>”,
            }

        
    

Contact lists

This is more of a concept, but what if we linked our contacts from our phones and mailbox to our vault? Would it be nice to receive an update when a friend changes their phone number or moves? And wouldn’t it be nice to see who actually has your number on their phone?

For this ID-Vault provides the contact list functionality, a contact list binds users to each other as is. Contacts lists use claim data but require no proof. Meaning that is is purposely possible to lie, distort or obfuscate through this feature. Equally so contacts can not be bound by dossiers and are therefore always and at all time’s deletable by either user. This means that a user can actively delete itself from another users phone book without that other user having to agree to this.

The contact list uses the /contacts endpoint under a users authorization token, https://id-vault.com/api/{user_uuid}/contacts. Contacts in themselves consist of three permission types: email, phone and address and contact object adhering to schmea.org. Meaning that a normal contact would look something like:

        
            {
                “contact”:{...},
                “email”:true,
                “phone ”:true,
                “address  ”:false,
            }
        
    

Users both ends of a contact connection can remove permissions, but adding a permission requeres mutual consent. Contact details are shared on a “i;’’ show you mine if you show me yours” basis meaning that permissions always work BOTH ways. With the node that no proof is required so while user A might get user B’s, he or she has no way of validating there data.

Required Scope: contact_list


Tracking Cookie

ID-Vault wouldn't be ID-Vault if we didn’t have some thoughts on tracking cookies. So that why we offer our own cookie alternative. That, does not collect data about users but collects data for users.

So how does that work? When you place the ID-Vault trace code on your website the users actions aren’t logged to a big data set where you can analyse them. Instead they are logged to the respective user wallet’s (if that user is known to us) or to anonymized dataset.

What does that mean?
In general an applications gets way less info then with (for example) an facebook or gmail tracing cookie. You see what amounts of users visit what page, how long they stay there and when they leave your website. You won’t see there age, sex, etc. And you cant follow individual users trough your website.

So wait, this provides way less information then google? ehm, yes…. that exactly the point.
So way should I use it as an application? First of all (since we don’t follow behavior) you won’t need a cookie warning, but more importantly because its the right thing to do.
But here is a twist, since a user has al of his account in its vault it can actually choose to share its data with you (that goes a bit further then a cookie warning). In that case you can trace actions to a specific user and actually get more data then you get with for example google. You just need to convince the user to voluntarily share it with you.


Authorization request

At any given time it might be necessary for an application to request access to a data’s user without the user performing having an authorization token. For example because you want to perform a user migration, and don’t know whether a user is already on id-vault.
This can be done by sending a POST to the /getScopes endpoint.


Creating Users

When switching your user base to ID-Vault you might need to create users that do or don’t exist in ID-Vault. You can create users by making a POST to the /user endpoint, user are then made unique by e-mail address. This means that making a user can have one of three results

  • The email address is invalid, or not in use (an error is thrown).
  • The email address is not currently claimed by an account
    • A user is created
    • The users claimes are filled by your provided data
    • An authorization code is automatically created with scopes for the supplied data and returned
  • The email address is currently claimed by an account
    • A claim requests is created for any provided data that is not currently part of the users identity wallet
    • An authorization request is created for all scopes within the supplied data.


User migration

When switching your user base to id-vault you will probably need to perform a mass user migration, this sounds more tricky then it is. But to do it right you want to take care of some crucial steps.

First we need to be aware that the creating users functionality handles most logic of figuring out whether or not a user should be created and so on based on a user's email address. That means that from a business logic point of view you can just make a script to iterate trough all your users, post them to the id-vault user endpoint and handle any or all requests

So lets take a look at what might happen, you post a user to the user endpoint and one of the following thing happens.

  • The email address is invalid, or not in use (an error is thrown).
    • You should probably delete this account from your own system
  • The email address is not currently claimed by an account
    • You get an authorization token, and can continue normally
  • The email address is currently claimed by an account
    • You need to alert the user to migrate there account


User Groups

As a matter of design OAuth en OpenId Connect offer Authentication (that is they determine who is who). As a developer you might however prefer to handle part of the Authorisation (who has wichs rights) process as a part of the general login process.

A normal authorization process calls for a user to be part of user groups, these user groups in turn have specific rights. YDoh you definitely want to check the rights of user groups on your applications itself but you can defer the registrations of user groups to ID-Vault as a part of your application's authorization token.
This basically saves you the huzzle of setting up your own system for user groups.