Open RieksJ opened 2 years ago
Rieks - thanks for this input. It's great. At this stage in the game we're pushing on a deadline, so I am guessing we will need to move some of these ideas to the future. I think we can do them relatively lightweight and quick way, though - through Wiki entries and blog posts. That said, perhaps you have a resource that can dedicate the time in the next week or two?
@darrellodonnell: Sorry for the late reply - I just returned from holidays (in which I was offline). Where do you suggest "we can do the relatively lightweight and quick" contributions? What wiki(s)/blog posts (which location)?
Rieks - thanks for this input. It's great. At this stage in the game we're pushing on a deadline, so I am guessing we will need to move some of these ideas to the future.
Could I suggest that an additional label eg. FutureRelease (or similar) be added to issues where ideas, conversations and thoughts are being reviewed for a new version?
@sankarshanmukhopadhyay Thanks for the reminder. I have changed the label to status: deferred
to reflect the consensus that this is a change we need to consider either in PR2 or in V2.
ISO 42010 defines 'architecture' as: "the fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution", which are expressed in an Architecture Description (AD). Specifically, an AD lists the various stakeholders, the concerns they have, and it uses "viewpoints" and "views" to describe how (groups of) concerns of (groups of) stakeholders are addressed by the system (of interest).
This issue is about discussing whether or not we want to engage in (a) identifying various stakeholder roles, (b) listing typical concerns of each of them, and (c) devising viewpoints that architects may use to instantiate (as views) as they seek to document how, for their specific system of interest, how these concerns are addressed.
I see the concept "system of interest" as the core element (as does ISO 42010), but then, I would also see that various parties that participate in a broader SSI context would each have their own 'system of interest' for which they would seek to address the concerns of their (mostly internal) stakeholders as illustrated generically by the following picture
and if we replace the generic functions with some SSI-specific stuff:
The figure shows how different parties can issue, hold, verify and revoke credentials, and if we need other functionality there, it could be added. Then,
issuer
,holder
,verifier
,revoker
and perhaps some others would be stakeholder roles, for which general concerns can be devised, and ways to address them. There would also be other roles, e.g.wallet-service-provider
,SSI-services provider
,SSI infra services provider
, and there may be more. General concerns for Parties 1, 2 and 3 would be things likeMy guess is that doing a writeup along these lines will provide a thorough yet practical basis for doing TOIP Architecture. Whatsay?