La identidad auto soberana es una identidad portátil de por vida para cualquier persona, organización o cosa que no dependa de ninguna autoridad centralizada y que nunca se puede quitar. La identidad auto-soberana es un modelo de relación bipartidista, sin un tercero entre usted y la organización, ahora considerado su "compañero".
SSI es posible hoy con DIDS y credenciales verificables.
DID es un nuevo tipo de identificador (URI) globalmente único que no requiere una autoridad de registro centralizada porque el control del identificador puede probarse utilizando la criptografía. Puede pensar en ello como uno de los identificadores con los que estamos más familiarizados, un nombre de dominio o un número de teléfono, sin un registrador central como ICANN o NANP.
La credencial verificable (VC) es el nuevo formato para la credencial digital interoperable definida por el grupo de trabajo de reclamos verificables W3C. Las credenciales verificables se ajustan al modelo de datos de credenciales verificables del W3C, y facilitan las interacciones utilizando un patrón llamado Triángulo de la confianza:
Los emisores crean credenciales, generalmente al hacer que JSON DOCS firme digitalmente de manera especial. Los titulares los almacenan, y los verificadores solicitan pruebas basadas en ellos. Las presentaciones verificables que los titulares proporcionan a los verificadores son paquetes de evidencia, ya sea credenciales o datos derivados de una o más credenciales, construidos por los titulares para satisfacer los requisitos de un verificador. Los verificadores aprenden con certeza qué emisores han atestiguado algo al verificar las firmas digitales contra un registro de datos verificable (generalmente una cadena de bloques).
React MSDK se construye utilizando Evernym Mobile SDK como un paquete nativo de React Compatible React que permite la construcción rápida de billeteras digitales personalizadas (completamente bajo su control) que representa un lado del soporte en el modelo de credenciales verificables.
Con el SDK móvil react-nativo, su aplicación puede:
La aplicación de billetera de identidad permite innumerables casos de uso, incluida la prueba de una edad legal específica sin revelar su fecha exacta de nacimiento, compartir registros de salud de forma privada y segura, y eliminar el concepto de nombre de usuario y palabras de pasas de una vez por todas.
Para la prueba de su billetera de identidad, puede usar Verity SDK que representa el lado de comunicación opuesto.
En los repositorios SDK y Verity SDK de Evernym Mobile puede encontrar mucha información útil sobre las billeteras de identidad de construcción y el proceso de intercambio de credenciales verificables.
Para crear un nuevo proyecto, deberá seguir los siguientes pasos.
Crea un nuevo proyecto de React Native. Lo llamaremos awesomeMsdkProject para esta guía.
npx react-native init awesomeMsdkProject --version 0.65.1 Nota : Debe usar la misma versión de react-native como se especifica en la sección peerDependencies de package.json File para el Evernym React-Native-Native-SDK. La versión react-nativa reaccionada actualmente es 0.65.1 . Al usar una versión diferente, corre el riesgo de tener problemas con SDK.
Para incluir SDK en su nueva aplicación, debe configurar sus dependencias.
Reemplace la sección de dependencias dejando solo @evernym/react-native-white-label-app Dependency a su package.json .
"dependencies" : {
"@evernym/react-native-white-label-app" : " https://gitlab.com/evernym/mobile/react-native-white-label-app.git " ,
}, Las dependencias nativas deben establecerse en las dependencias de la aplicación (ver problema). Se enumeran como dependencias de pares en SDK.
Agregue todas las dependencias de pares de @evernym/react-native-white-label-app en la sección dependencies de su package.json de aplicaciones.json.
"dependencies" : {
"@react-native-community/async-storage" : " x " ,
...
"react-native-zip-archive" : " x " ,
"react-native" : " 0.65.1 " ,
"rn-fetch-blob" : " x " ,
...
}, Agregue todas devDependencies de @evernym/react-native-white-label-app en la sección devDependencies de su package.json aplicaciones.json.
"devDependencies" : {
...
"copyfiles" : " x "
}, Agregue el siguiente comando a su sección scripts del package.json de su aplicación.
"scripts" : {
...
"evernym-sdk:configure" : " yarn --cwd node_modules/@evernym/react-native-white-label-app run configure "
}, Este comando agregará módulos necesarios para la personalización futura de aplicaciones a través de evernym-sdk .
Ahora puede instalar todas las dependencias y hacer la configuración automática, ejecute los siguientes comandos en su directorio de proyecto:
yarn
yarn evernym-sdk:configure Esto instalará todas las dependencias y agregará módulos requeridos al directorio awesomeMsdkProject/app/evernym-sdk .
Elimine App.js predeterminada y coloque lo siguiente en index.js :
import * as EvernymSdk from '@evernym/react-native-white-label-app' ;
import { name as appName } from './app.json' ;
EvernymSdk . createApp ( appName ) ; Navegue al archivo app/evernym-sdk/provision.js y defina el entorno para ser utilizado por su aplicación y función para ser llamado para obtener tokens de aprovisionamiento.
Tenga en cuenta que el entorno de aplicación debe coincidir con el entorno donde el servidor patrocinador está registrado.
Por ejemplo, la aplicación debe usarDEMOsi el servidor de patrocinador se registró en el entornoDEMO.
DEFAULT_SERVER_ENVIRONMENT : el nombre del entorno a usar.
Hay varios entornos predefinidos:
// use default combination - DEMO for debug and PROD for releases builds
export const DEFAULT_SERVER_ENVIRONMENT = null
// use Demo env
// Agency: `https://agency.pps.evernym.com` and `Sovrin Staging Net`
export const DEFAULT_SERVER_ENVIRONMENT = 'DEMO'
// use Production env
// Agency: `https://agency.evernym.com` and `Sovrin Live Net`
export const DEFAULT_SERVER_ENVIRONMENT = 'PROD'
// use Staging env
// Agency: `https://agency.pstg.evernym.com` and `Sovrin Staging Net`
export const DEFAULT_SERVER_ENVIRONMENT = 'STAGING' También puede proporcionar y usar su entorno personalizado utilizando una combinación de variables SERVER_ENVIRONMENTS y DEFAULT_SERVER_ENVIRONMENT :
export const SERVER_ENVIRONMENTS = {
'CUSTOM' : {
agencyUrl : 'ahency_url' ,
agencyDID : 'did' ,
agencyVerificationKey : 'verkey' ,
poolConfig : [ { key : 'staging' , genesis : 'genesis_transactions' } ] ,
}
}
export const DEFAULT_SERVER_ENVIRONMENT = 'CUSTOM' GET_PROVISION_TOKEN_FUNC : se llamará a la función para obtener un token de aprovisionamiento de agente para su aplicación.
/// example
export const GET_PROVISION_TOKEN_FUNC = async (): [error: string | null, token: string | null] => {
try {
// call your sponsor server endpoint
const response = fetch_api(your_endpoint)
// process response
// return result in format [error, token]
return [null, response.token]
} catch (error) {
return [error.message, null]
}
}
¡Felicitaciones! Ahora tenemos una parte de la aplicación lista. Como los próximos pasos, necesitamos configurar la compilación para las plataformas de destino.
Nota : En este punto, ya debería haber completado la sección de configuración de la aplicación base.
Para configurar la construcción de su aplicación para una plataforma Android, consulte el documento.
Nota : En este punto, ya debería haber completado la sección de configuración de la aplicación base.
Para configurar la construcción de su aplicación para una plataforma iOS, consulte el documento.
Consulte la documentación para obtener una descripción general de las opciones de configuración disponibles.
Este esfuerzo es parte de un proyecto que ha recibido fondos del Programa de Investigación e Innovación del Horizon 2020 de la Unión Europea bajo el Acuerdo de subvención no 871932 entregada a través de nuestra participación en el ESSIF-LAB, cuyo objetivo es avanzar en la amplia adopción de la identidad auto-soberana para el beneficio de todos.