Message Body new attribute: assertedIdentity

[pchainho]

@Ricardo-Chaves @KCorre I'm proposing a new assertedIdentity attribute in the message body that will be only present in local runtime messages (delivered by the Message BUS to local Hyperties) that contains an Identity object. The data to be set in this attribute by the Identity Module would be the result of the process of decoding and verification of JWT tokens contained the incoming Message:

https://github.com/reTHINK-project/architecture/tree/master/docs/datamodel/message#message-body

What do you think?

[KCorre]

I'm not sure what the purpose of such an attribute would be.

At the moment Identity Token are used

• Send: to authenticate to another user (Alice to Bob)
• Send: to authenticate to a service (Alice login to Service)
• Receive: to authenticate someone before establishing a conversation (Bob to Alice)

Why would an Hyperty get an Identity Token?

• Receive case: to get a proof that the user on the end of the line is indeed Bob. So after token verification, the IdModule confirm that the token is valid. But in this case the Hyperty already had it as it received it through signaling.
• Send case: either to login or authenticate Alice, the Hyperty could receive the newly generated token and send it to the backend server or to Bob through signaling for authentication. But in these cases the identity token is sent at most only once.

Also

Could you clarify what is the goal of this attribute?

Edit: I see that it's not the IDToken but the decoded IDToken. My remarks are still valid as to when it is set and what is the purpose. I add some others questions. :)

• Are we talking on Alice's runtime of Alice's or Bob's identity?
• The Hyperty doesn't need a human readable identifier except for displaying information to the user? Is it one?
• If not, the IdToken would already have an identifier (a userId) common to the IdP and the service backend. The userId would already be present in the IdToken so that the service can verify it.

[KCorre]

Message Body

Optionaly, all message bodies exchanged between different Runtime Messge BUS can contain JWT tokens for Access Control for Identity Assertion purposes that are inserted by the Identity Module before the message is routed to protostubs.

When these message bodies reach the destination MessageBUS, the JWT tokens are decoded and verified by the Identity Module. The result of this process (if successful) is inserted in the MessageBody as assertedIdentity objects and the JWT tokens removed, before the message is delivered to the Hyperty. AssertedIdentity is compliant with User Identity Data Model.

• Why runtime messages would contains Identity Assertion?
• If the IdModule set a JWT tokens before routing the message, why does the JWT tokens need to be decoded by the IdModule before reception? As I read it it's like the IdModule is encoding and decoding the IDToken at the same time.

The IdModule is used to interface several Identity Provider into a single interface for authentication (and maybe login) to externel principals. We need to clarify why an hyperty would need an identity assertion from inside the runtime.

[pchainho]

The idea is that Hyperties don't handle JWT tokens but only the Id Module.

I suspect that we are saying the same thing :) but let's use Alice invites Bob call example, to check:

At Alice Runtime: 1- Alice's Hyperty sends a Message inviting Bob without any JWT token in the message 2- According to applicable Policies Policy Engine requests IdModule to generate a JWT Token for Alice's Display Name, Avatar and UserIdentifier. 3- The JWT Token is inserted in the Message Body and Message routed to Bob's Runtime

At Bob's Runtime 1- Message reaches Bob MsgBUS that requests the Policy Engine to authorise the delivery of the message 2- Policy Engine requests the Identity Module to decode and verify JWT Token 3- If successful, the decoded Identity data is inserted in the Message Body and JWT Tokens removed. 4- The Policy Engine authorises the Message Delivery to Bob's Hyperty, which does not contain any JWT Token but only verified data about Alice identity that Bob't App can trustfuly present to Bob

Does it match?

[Ricardo-Chaves]

I believe you are indeed saying the same thing. It matches.

[KCorre]

Ok I get it.

• The JWT is not encrypted but encoded and signed. The signature need to be verified but the information in it is already accessible by decoding the base64 string. Once it is verified by the IdModule do we need to permanently decode it (as you explained) and remove the JWT or should we just send the JWT (which can be decoded by any javascript). If we remove the JWT and don't keep the signature it can't be verified again. Would it be useful?
• Is the "assertedIdentity" protected from external modification (not runtime)? In WebRTC one of the claim is that the CSP is not trusted for identity verification. But if it's the Hyperty (CSP) that displays the identity it's not the same trust model (as the hyperty could claim any identity).

So in the example you give the CSP/hyperty get a proof that the identity is legit but if the user does not trust the CSP it have no proof of validity as the hyperty could display anything and the JWT is removed. (e.g. untrusted poker site). Any component capable of modifying the unsecured "assertedIdentity" would also be to do that.

[pchainho]

I thought this one was already closed.

The JWT is not encrypted but encoded and signed. The signature need to be verified but the information in it is already accessible by decoding the base64 string. Once it is verified by the IdModule do we need to permanently decode it (as you explained) and remove the JWT or should we just send the JWT (which can be decoded by any javascript). If we remove the JWT and don't keep the signature it can't be verified again. Would it be useful?

probably we can keep it to allow a second verification by the App. "assertedIdentity" is used in order to have a standard user identity format that is agnostic of the IDP. Actually, it would be useful to separate the identity data from the information it was asserted or not (boolean) to also have the possibility to deliver non asserted identity data.

Is the "assertedIdentity" protected from external modification (not runtime)? In WebRTC one of the claim is that the CSP is not trusted for identity verification. But if it's the Hyperty (CSP) that displays the identity it's not the same trust model (as the hyperty could claim any identity).

So in the example you give the CSP/hyperty get a proof that the identity is legit but if the user does not trust the CSP it have no proof of validity as the hyperty could display anything and the JWT is removed. (e.g. untrusted poker site). Any component capable of modifying the unsecured "assertedIdentity" would also be to do that.

since the "assertedIdentity" is generated inside the core runtime that is considered a trusted computing base, and as Alice identity is displayed by Bob's CSP App / Hyperty, I would say yes. But I would like to hear more opinions from the security experts here. I guess, we can also have the option to let Bob check Alice's identity through some native GUI from the "Identity Module"