search

reTHINK-project / core-framework

The main goal of WP3 is to provide the reTHINK core framework comprised by the runtime environment where Hyperties are executed and the messaging nodes used to support messages exchange between Hyperties.
Apache License 2.0
1 stars 0 forks source link

Runtime Main Procedures for Identity Management: complete and clean #77

Closed pchainho closed 8 years ago

pchainho commented 9 years ago

https://github.com/reTHINK-project/core-framework/blob/master/docs/specs/runtime/dynamic-view/identity-management/readme.md

Complete with Runtime APIs functions and Messages samples using D2.2 Data Model. See this example

Split diagrams if too big

pchainho commented 9 years ago

What is the status ?

Ricardo-Chaves commented 9 years ago

waiting for updates on the user-identity-assertion image.

Ricardo-Chaves commented 9 years ago

Waiting for the completion of Discovery.

Should we maintain the text "Identity Management dynamic view" (at the begging of the identity-management).

Regarding "User Profile Management":

pchainho commented 9 years ago

I suggest we skip this for D3.1 but I've already provided some ideas in D2.1 where User Profile would be managed by an Hyperty Identity type. Check step 23 at:

https://github.com/reTHINK-project/architecture/blob/master/docs/dynamic-view/registration%20and%20login/UC4_Registration_with_external_id.md

KCorre commented 9 years ago

The text Identity Management dynamic view if I recall was only some questions to clarify on calls. The big picture was not meant to be public but used to start discussion (or clarify my view). I'm taking the concepts shown here to produce the D4.1 IdModule section.

I updated the image identity-assertion.

But all in all I'm a bit confused on the task affected to WP3 and WP4 concerning identity. As I see it the IdModule is providing an API for others components (hyperties, runtime) to use. This API provide identity assertion generation and verification capability (mainly) as well as other features (trust, ...). WP3 would thus only be concerned with how and what for use this API. Everything happening behind the scene would be described in WP4. So that would be the interface point of the two WP but also a limit of concerns.

I should have asked that before, but as I said I'm a bit confused by the separation of task. And by looking at the diagram I produced (id assertion verification) I think that specifying "IdP Proxy" in WP3 and WP4 is hard to follow. I may be totally wrong, if that's the case please clarify. :)

@jmcrom @sbecot you opininon?

Note: The discovery service would be another interface point as I don't think that the core runtime depends on the DHT structure behind it. ReNote: Some diagram use the "identities" object. It should probably be renamed as IdModule.

pchainho commented 9 years ago

In my view Identity Module is part of the Core Runtime and T3.2.

pchainho commented 9 years ago

@KCorre could you check if you have committed to the right place, pls? I don't see any change

jmcrom commented 9 years ago

@pchainho @KCorre @sbecot I think developing idModule is part of T4.3 "implementation of IdM components" even though it has to be coordinated with T3.2

KCorre commented 9 years ago

Commit 3 days ago: https://github.com/reTHINK-project/core-framework/commit/494c805ad7c098ce8962092bff0e37ce525dcf9d