Architecture according to ISO 42010

[RieksJ]

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 like

• "for the purpose of realizing this specific objective of mine: what kinds of data do I need (syntax, semantics), AND what kinds of assurances do I need that make my processing that data valid (which is prerequisite for a valid result)?"
• "how can I, or my employees, or the IT I use as an agent, create requests for such data, determine the validity of responses (and further process it)?"
• "how can I devise policies (working instructions, configuration files, ...) that my employees and IT can read, understand and use in their fulfilling my role of issuer, holder, verifier, revoker (and what not)?"

My guess is that doing a writeup along these lines will provide a thorough yet practical basis for doing TOIP Architecture. Whatsay?

[darrellodonnell]

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?

[RieksJ]

@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)?

[RieksJ]

I've put some texts here that might be useful

[sankarshanmukhopadhyay]

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?

[talltree]

@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.