Re: Architecture Stages, and options of Subject-Holder

On 6/14/2016 8:44 PM, Manu Sporny wrote:
> On 06/14/2016 06:27 PM, Steven Rowat wrote:
>> These two problems (time flow, and the optional "Subject is Holder"
>> and/or "Holder is Issuer") bothered me also. They're the main reason
>> I began formulating a different layout.
>
> To clarify (via exhausting the combinations):
>
> A Subject is what a Claim is about.
>
> A Holder can assume the role of Subject.
> A Holder can assume the role of Issuer.
> A Holder can assume the role of Consumer.
> A Holder can assume the role of Repository.
> A Holder can assume the role of Inspector.
...


Forgive me, but I believe the is not correct.

A given entity might assume different roles.  But in an architecture 
description, what is described is the roles, not the entities who assume 
those roles.  And one role does not 'become' another role.  Rather an 
entity might move from one role to another.

For email, a person who authors an email can of course also be a 
recipient of email.  However it is not that the author 'becomes' the 
recipient, but rather that a given person performs these different roles 
at different times.

I believe this issue is merely another example of the challenge at 
separating issues into proper levels.  In the case, a person or 
organization is the highest level construct, under which they can assume 
different roles at different times.

FWIW, though I'm not pursuing the concern, given the time constraints, I 
believe we will find that assigning the creation of identifiers to the 
Holder, rather than to the Subject, is going to turn out to be 
problematic, because it conflates claims processing with identification 
processing.

Conflation is usually a problem that comes back to bite some unfortunate 
part of our anatomy we have a hard time seeing, but the pain is quite 
unpleasant...

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Received on Wednesday, 15 June 2016 03:23:24 UTC