In corda, In order to hide identity of corda nodes in transaction, Confidential Identities being used. As per corda documentation, Confidential Identities issued by Well Known Identity Certificates.
Below are few questions related to corda confidential Identity :
How notary (Service Identity) checks signature on transaction if it consist of confidential key?
How corda linked up Well-known Identity with confidential Identity? What extra information required to linked up confidential identity with well-known identity?
If perform transaction between PartyA and PartyB with confidential identity using SwapIdentityFlow, now perform same transaction between PartyB and PartyC, will PartyC resolves all dependency including confidential identities from PartyB. As per walking transaction chain dependency resolved from proposer of transaction, so without any IdentitySyncFlow will it work?
How nodes verify signatures on SignedTransaction ? Is it only based on public key?
Thank you in advance.
The required signers on a transaction are listed as public keys, not Party objects. If you want to sign a transaction using a confidential identity, you just list that confidential identity's public key as a required signer on the transaction instead of your well-known identity's public key. Then verifying the signature does not require knowing the corresponding identity.
Each confidential identity is linked to the corresponding well-known identity using a certificate chain. However, this certificate chain is only distributed on a need-to-know basis, so that only specific nodes can link the confidential identity to a well-known identity.
Walking the chain does not require resolving confidential identities to well-known identities. Thus PartyB and PartyC can transact without PartyC knowing that PartyA was involved earlier in the chain.
Yes. See the answer to 1.
Related
Does Corda support user credentials for Accounts / Party? Here there is a common username, password for the node access through RPC. Is there a way to validate the user (Node user / Account) in Corda as well?
Application user (Node user / Account) <----> Application <----> RPC Client <----> Cordapp (Node)
the only way to connect an external client to a node is using the Corda RPC Client
the configuration of the user that can connect to the RPC Client (i.e. username, password, permissions) is in the node.conf (explained here)
you can create multiple users in the node.conf. Up to you to assign these users to a node administrator, or to external users, depending on your security policies. You can set different permissions for each of them, and also set which CorDapp flows they can access to.
If your CorDapp does use Accounts (i.e the account library), and you want them to "run flows" (though, consider that accounts in Corda do not run flows, but it's always the node that run flows on their behalf) from an external client (e.g. a Web app), you have the possibility to:
create a RPC user in the node.conf for each account
create only one user for the RPC client and manage the authentication and authorization of the external users at application level, not Corda level (e.g. JWT, external database, AWS Cognito, etc..). Once authorized, the user can access the RPC client from the Web app and
a mix of the 1. and 2.
I would not recommend to delegate the authentication and authorization of external users only at Corda level. I would keep the concept of "accounts" in Corda and "external users" separated.
How is X.509 certificate for a confidential identity signed? Does the node signs it with it's node certificate? Or is it signed with node's well-known signing identity?
How is it avoided that the certification chain can not be followed back from the signature created by the confidential signing identity? For instance, in the cash usecase where historic states back to the issuer have to be presented in order to be able to validate cash transactions.
The node's well-known identity issues and signs certificates for each one of its confidential identities.
It only shares the certificate chain linking a confidential identity back to its well-known identity on a need-to-know basis.
If a node inspects a transaction chain where a confidential identity has been used for which they have not received the certificate chain, the node will simply see an anonymous public key that they cannot link to a well-known identity.
I'm writing a web application with spring boot and want that the user is able to tell me what his identity provider is. In a same way as I can do it on Stackoverflow.
How can I identify a user in a unique way? I already read that I should use the sub/Subject for distinguishing users. Is this unique when using multiple providers?
My fear is that a user provides a malicious identity provider which then tells my app he is a different user.
How can I identify a user in a unique way? I already read that I should use the sub/Subject for distinguishing users. Is this unique when using multiple providers?
You'd store the combination of (iss, sub) as an identifier that is globally unique. As Kavindu mentioned already, the sub claim by itself is only locally unique.
My fear is that a user provides a malicious identity provider which then tells my app he is a different user.
There are two ways of using "multiple providers" with your app, via:
a set of trusted IdP's
any IdP
If someone's real identity is important to you, then you can choose the providers you trust to provide someone's identity details. People then can only sign in via one of the providers in your list.
But if it doesn't matter that much (normal username/password registrations also don't provide any guarantees), then you could also choose to let people login with a provider of their choosing. The correct provider may then be discovered from the user's "handle" via OIDC Discovery.
Q : How can I identify a user in a unique way? Is this unique when using multiple providers?
According to OpenID Conenct specification, "sub" claim is locally unique. Following is the extraction from specification which highlight this (reference),
Subject Identifier. A locally unique and never reassigned identifier within the Issuer for the End-User
So when you are dealing with a single identity provider, "sub" claim is unique. But that does not hold for multiple providers.
Q : My fear is that a user provides a malicious identity provider which then tells my app he is a different user.
I doubt about this scenario. Does your application allow end users to register different identity providers as they want ?
In OpenID Connect, there's a application registration step. Your application need a client identifier. Also registration process involve redirect URL registration. All these are done in registration step. Without these, OpenID Connect will not function.
Adding to that, different providers behave differently. For example, though "sub" is the standard claim to communicate end user identity, a provider may use a custom claim to define a specific user identity. This is allowed by OpenID Connect specification. So your application must only support known, well established identity providers which you know at the application design time.
Just wanted to confirm my understanding on the User Verifiers in Kaa.
The primary purpose of user verifier is to enable Kaa eventing and interaction between endpoints. Is there any other application of a user verifier ?
The main purpose of the user verifiers in Kaa is to attach an endpoint to a particular Kaa user. That implies not only endpoint-to-endpoint communication within the scope of the same user, but also a number of other bindings and relations between features and data in Kaa.
I'm developing an ASP.Net Core web application and will be using Auth0 for user authentication.
I'm having a hard time figuring out if my JSON Web Token Signature Algorithm should be RS256 or HS256.
From the information that I have found, I still can't make heads or tails of it. Any ideas?
Even though both algorithms make use of SHA-256, they are fundamentally different:
RS256 (RSASSA-PKCS1-v1_5 using SHA-256) relies on generating a digital signature with a specific private key.
HS256 (HMAC using SHA-256) relies on a shared secret plus the cryptographic hash function (SHA-256) to generate a message authentication code (MAC).
Validating tokens issued with each of the previous algorithms implies that for RS256 the entity doing the validation knows the public key associated with the private key used for signing, while for HS256 it implies that the entity knows the shared secret.
Choosing between one versus the other is then usually motivated by the characteristics of the applications that will validate the issued tokens.
If you want to validate a token on a browser-based application, the use of HS256 is automatically ruled out because that would imply you would have to include the shared secret in a place anyone would have access, making it completely useless because now anyone with access to the code could issue their own signed tokens.
In conclusion, if token validation is done on a controlled environment (server-side) you may go with HS256 because it's simpler to get started. However, if token validation is done on hostile environment you need to go with an algorithm based on asymmetric cryptography; in this case that would be RS256.