uPort/Lobby

Welcome to the uPort lobby!

Didi

@d10r

@Taimoor10 it's all easy as long as I only want my Apps to interact with each other. But for interoperability, it's important to speak the same language.
According to that doc (thx for the link), it's at least partially based on OpenID claims spec. I hope that in the future there will be convergence with projects like Hyperledger Aries,Kantara Initiative, IHAN Blueprint etc.

As I currently see it, uPort does a great job at building tooling and approachable demos.
It's not so clear to me if uPort is well integrated into standardization efforts. The space still seems to be quite fragmented.

Nguyễn Phúc Tú

@phuctu1901

Hi, i'm newbie. And i have a problem when using uPort. If I have a credential with attribute A,B, C, etc, is it possible to present claim A without revealing the whole credential (B, C, etc)?
How ?

Muhammad Taimoor

@Taimoor10

@d10r you are right. It says here https://developer.uport.me/messages/sharereq that claims are somewhat based on OpenID-Connect and it would be great if uPort improves their documentation and make these things clear. There is certainly need for it

Mircea Nistor

@mirceanistor_twitter

@phuctu1901 It is not possible at the moment.
uPort recommends using atomic credentials to achieve this.
So, in your case you would receive 3 separate credentials, A, B, C. then you'd be able to share them individually.

@Taimoor10 @d10r yes, that spec is indeed based on OpenID-connect.
At the moment there is no final standard regarding credential request/replies but uPort is working towards interoperability.

This will also mean that legacy protocols will be unmaintained when that happens.

Muhammad Taimoor

@Taimoor10

@mirceanistor_twitter Thank you for providing this information. and it would be really nice to have interoperable features

Mircea Nistor

@mirceanis

I see many potential bugs being discussed here, many without resolution.
Generally it's better to post these on github.
The uPort team, unfortunately, doesn't have the resources to man this lobby too often, leaving people without answer.

Discussions are still very welcome, of course, but if you suspect there's a bug somewhere it fits better as a github issue.

Nguyễn Phúc Tú

@phuctu1901

@mirceanis thank you so much. I think it is a awesome method. But so difficult for explain to client :(((

Mircea Nistor

@mirceanis

@phuctu1901 Client can be unaware that 3 different credentials are involved. But this depends on how technical they are.

passionofvc

@passionofvc

Is there any code for sign ETH transaction use UPort credentials? https://developer.uport.me/credentials/transactions is not work for me.

Mircea Nistor

@mirceanis

@passionofvc, it's impossible to know what does not work for you. Please share abundant details about your setup and error messages to increase your chances of getting help.
Ideally, post the snippet of code that is failing and error details as an issue on https://github.com/uport-project/uport-credentials/issues .
Don't forget to remove any private keys from code before posting.

passionofvc

@passionofvc

@mirceanis I create sample use https://developer.uport.me/credentials/transactions but send error happened when I approved the request, show network provider is invalid,

passionofvc

@passionofvc

@mirceanis Is there any app run as UportID can use local truffle,Ganache node, local ipfs to save hash data, local transport push event service (chasqui) to debug how credentials work? UportId(mobile) has many build in https://id.uport.me/req/ https://ipfs.infura.io:5001/api/v0/add.

Rosario De Chiara

@rosdec_gitlab

hello everybody .. I hope this is the right place to get some entry level information .. i'm coming from a little experience made on SSI on Hyperledger Indy .. now trying to wrap my mind about how concepts of Indy maps on uPort .. is there any up-to-date document that may assist me?

0x012A

@0x012A

query : How does uport confirm that the 3rd party which verify the credential is genuine one ?

Smit Rajput

@smitrajput

Hi uPort tribe!

Quick question:

How do I get the IPFS hash of the credential that I just received from a small app in the 'We3 Login Example' guide in the uPort docs, to check whether it is actually stored in IPFS or not?

Dominic Morris

@7-of-9

Hi all -- very high level question, I think the answer is "no" but really need to be sure: is it possible to read uPort identity/claim data directly in an Ethereum TX, i.e. from Solidity code that runtime-references one or more uPort smart contracts?

I guess the signing account of the TX in question would need to be authorised by the identity owner to read the data, that is understood in principle. But is it even possible at all to do "on-chain" stuff like this in uPort? All the examples I could see talked about doing this with JWT, HTTP, JS, etc. -- not Solidity.

Mircea Nistor

@mirceanis

@0x012A every request is signed, so the uPort app can determine if it is the same identity that you interacted with before.

But the first interaction is important, as there is no other prior information. It is up to the user to determine trust then.

@smitrajput the credential is not stored on ipfs. It is stored in the local storage of the uPort mobile app, and optionally backed up in an end to end encrypted cloud storage if that is enabled in settings.

Mircea Nistor

@mirceanis

@7-of-9 as far as I know there is no easy way to verify and interpret JWT onchain. Also, it goes against uPort recommendations since it would expose that JWT forever to the world if it's part of a transaction.

But, it should be possible to verify a simpler signature coming from a uPort account, in an onchain authorization scenario.

Mircea Nistor

@mirceanis

Also, the uPort mobile app can sign EIP712 typed data, which can be used as a credential format that is theoretically verifiable onchain. The same privacy concerns apply as with JWT if the signed typed data is part of a transaction though.

Dominic Morris

@7-of-9

Thanks @mirceanis , appreciate your input. My use case is for a ERC1404 security token, specifically in verifying recipient eligibility in the case of an erc20 transfer TX. Here, the EVM/runtime erc1404 would really like to verify the claim(s) for the token recipient, to check that he is authorised to receive the security tokens. Seems to me that on-chain verification of claims is a very key requirement.

Shyam Pratap Singh

@spsingh559

Is there any guide/documentation to build your own uport mobile wallet and stored credentials and share with authority like uportlandia interaction?

Shyam Pratap Singh

@spsingh559

Hi everyone, I would like to know the status of Uport/DAF, can we use this framework for building an identity solution, I have not find documentation regarding DAF except Github. Any help would be appreciated.

Mircea Nistor

@mirceanis

Hi, Shyam.
DAF is the framework we're focusing on now and for the foreseeable future.
It is meant to unify most of the common protocols and formats developed by the W3C and the Decentralized Identity Foundation(DIF) as they relate to Decentralized Identifiers(DIDs) and Verifiable Credentials(VCs).
It is in early development and github is at the moment the best place to get help about it.

Nhan Le

@NLe1

Hi guys,

I am trying to set up uPort with local private Geth client Ethereum network but the best I can try is to follow this github https://github.com/uport-project/private-net-example, but unable to set up because of some JWT problem. Have any of you guys have ever tried this ?

I noticed that the uport-cli is deprecated and there are some use case of this repo that really help in my case

so are uPort going in this direction of supporting the developer's use case which is deploying uPort identities on private network?>

Thanks for reading

Héctor Iván Hernández Castelán

@HeckCas_gitlab

Hey guys! I wanna ask, which is the best way to obtain only the public address of a user, generating to the user a Qr and sending him to scan it to receive public address in my server. I'm currently using the "credentials.createDisclosureRequest" and creating a Qr but in the callbackUrl i dunno how to send it back to the frontend or to the creaQ-Endpoint

Sohrab Quraishi

@sohrabq

hello mates,

i have a problem in uport appmanager website while scanning the QR Code to login it gives the error while formatting outputs from RPC '{"value":{"code":-32002,"message":"rejected due to project ID settings"}}'

could any one help me out please

Ross Bernard Jamaca

@rbjamaca

Where to refer if I wanna do the implementation where credentials get saved to the blockchain?

Ross Bernard Jamaca

@rbjamaca

Hello?

Mircea Nistor

@mirceanis

@rbjamaca please, NEVER save credentials to the blockchain!
Not even encrypted.
It is fundamentally not scalable, it can be very expensive and in many cases it may be a privacy breach and a GDPR violation.

All the work the uPort team has done was to prevent exactly this

Ross Bernard Jamaca

@rbjamaca

I understand @mirceanis . Anyway, while testing some of the examples, i've just noticed that some stuff are not currently working especially about disclosure requests on uport-credentials.

Mircea Nistor

@mirceanis

Sadly we don't have the bandwidth to maintain the full uPort stack anymore.
All of our efforts are now focused on the Veramo framework ( https://github.com/uport-project/veramo ) and the libraries that uPort has donated to the Decentralized Identity Foundation.

If you are just starting out, it would be a good idea to check out https://veramo.io instead of relying on the uport-credentials / uPort mobile combo.
It is not yet a full replacement for the uPort stack (and I'm not sure if it will ever be a 1:1 mapping there) but the goal is to provide a standards-compliant, multi-platform framework for decentralized identity and verifiable credentials that can also interoperate with other projects and efforts in this space.

Ross Bernard Jamaca

@rbjamaca

Thank you for pointing me to the right direction. I'll give veramo a try.

yiannakpavy

@yiannakpavy

I apologize for being naive, but are there fees associated with creating a uPort identity? Everything I have read claims that these fees are payed by a fueling server, and that the uPort identity is the address of the proxy contract on the Ethereum chain (mainnet?). Can anyone offer some clarification?

Mircea Nistor

@mirceanis

Hi, @yiannakpavy. It's not naive :) Indeed uPort was using this model in the first version, but that has changed a long time ago.
The latest versions of uPort no longer use a proxy contract to represent an identity.
Instead, any ethereum address is considered an identity (see https://github.com/decentralized-identity/ethr-did-resolver).
Since these addresses can be created without interacting with the blockchain, it means that creating an identity is free.
If one needs to update the identity, then a transaction is required and that will cost some gas.
The smart contract on which this is based (https://github.com/uport-project/ethr-did-registry) allows a third party (like a fueling service) to pay for the transaction if the right signature is provided by the identity for which it posts.
This mechanism later got the name of meta-transaction.

That being said, please read my previous note about the state of the uPort stack: https://gitter.im/uport-project/Lobby?at=60422bb8823b6654d285dcc5
Please take a look at https://github.com/uport-project/veramo as this is where all the development work is being focused now.

yiannakpavy

@yiannakpavy

@mirceanis Thank you for the clarification and all the info! I think my confusion still lies in the notion of creating an Ethereum address without interacting with the chain. Does the address persist on the blockchain when created? Also, is the old version of uPort (using proxy contract as the identity) still being used/available? With respect to Veramo, is there a uPort-equivalent platform/app in development that encompasses SSI, eg, managing identities and credentials? (I apologize for bombarding you with questions)

yiannakpavy

@yiannakpavy

@mirceanis Sorry to bother, but I had a few follow-up questions. When you say a transaction is required to update the identity, is this analogous to updating the DID doc of the identity with attestations/attributes? Does uPort still support updating a uPort-specific decentralized registry (e.g., via the Registry Contract) that maps a uPortID to off-chain, disclosed data (e.g., via IPFS)? I'm trying to better understand the use cases supported here, e.g., on- vs. off-chain transactions, and how/when the blockchain is used.

yiannakpavy

@yiannakpavy

To supplement the discussion above, it looks like the current uPort application still implements the Proxy Contract. See https://github.com/uport-project/specs. Is that correct?

Where communities thrive

People

Repo info

Activity