OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

trust-el message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [trust-el] Groups - TrustEL Architecture v01.pdf uploaded


Nothing wrong in disagreement Peter – it’s back in fashion again.. J

I’ll be interested to hear what you think of V2.

Cheers

Colin

 

From: Andrew Hughes [mailto:andrewhughes3000@gmail.com]
Sent: Saturday, 24 January 2015 5:44 a.m.
To: Peter Alterman
Cc: Colin Wallis; trust-el@lists.oasis-open.org
Subject: Re: [trust-el] Groups - TrustEL Architecture v01.pdf uploaded

 

I'll work to ensure that the right level of detail is present at each abstraction level.

 

I'm still trying to find all of the common threads - on the calls there are more than one use case and flow being discussed intermittently, and it's hard to differentiate which discussions are about the primordial use case and the advanced use cases. Just to note that the stick and box pictures are mostly the sequence diagram from the primordial use case shown in a different format, plus a small bit of embellishment by me. The small bit of extra is to help get at the envisioned underlying mechanisms to ensure that the higher level abstraction is representing faithfully.

 

andrew.


Andrew Hughes CISM CISSP 
Independent Consultant
In Turn Information Management Consulting

+1 250.888.9474
1249 Palmer Road,
Victoria, BC V8P 2H8

AndrewHughes3000@gmail.com 
ca.linkedin.com/pub/andrew-hughes/a/58/682/
Identity Management | IT Governance | Information Security 

 

On Fri, Jan 23, 2015 at 8:16 AM, Peter Alterman <palterman@safe-biopharma.org> wrote:

Well, Colin, here's one of the few areas in which we disagree: I think it's very important for lower-altitude architectural and flow models to map back up to the high level flow we've been working from. Here's why: the Trust Elevation TC is chartered to develop standards (in our case Committee Specifications) that cover a broad range of implementations. In going to a Fourth Deliverable (unchartered, btw) the TC is developing a template for making the previous Committee Specifications functional, but it is only a template and other implementers out there may certainly roll their own, so long as they align their work with what we've produced. Without a clear path from a generic use case to a particular implementation of it (there are many implementations possible when deconstructing the boxes, as Andrew has observed), we run the risk of having the Fourth Deliverable be misunderstood, that we were trying to force all Trust Elevation use cases into our one deconstructed model. Therefore, I think it's important to show the high level use case, make clear it's just the most generic one we can imagine, and then show one particular deconstruction while also acknowledging that many others can fit under the model, and that the actors, transactions, data flows and metadata tags are an example of how to work through implementing TE for a particular case.

 

 I do agree with the rest of your comments. Naturally. ;-)

 

Peter


------------------------------------------------------------

Peter Alterman, Ph.D.

Chief Operating Officer
SAFE-BioPharma Association

cell: 301-943-7452

 

On Thu, Jan 22, 2015 at 6:14 PM, Colin Wallis <Colin.Wallis@dia.govt.nz> wrote:

Thanks for this Andrew

 

I thought it was a pretty reasonable start, given that it is a mix of taking the 4th deliverable forward, but in a way that you can check you have your understanding of the constructs so far, correct.

 

Mapping it to Shaheen’s earlier efforts is a later step IMHO.

 

Two things that I would have mentioned had we not run out of time (since they had not come up in conversation) were:

 

1)      An explicit reference to the fact that user consent flows have been missed out for the sake of simplicity. After all, in many B and C use cases, regulation/legislation would require directed user consent in the IdP/CSP to UA interaction.

2)      Probably a separate explanation of the (IMHO quite fine grained) distinction between a TE Selector, and TE Determiner and the role of the TEMSP.       Someone brought up the fine grained/depth of it (Peter?) but my feeling was that it was too much to expect to draw it as a box or 3 on a flow diagram and let readers make assumptions based on that.

Cheers

Colin

 

From: trust-el@lists.oasis-open.org [mailto:trust-el@lists.oasis-open.org] On Behalf Of Andrew Hughes
Sent: Wednesday, 21 January 2015 5:35 a.m.
To: trust-el@lists.oasis-open.org
Subject: [trust-el] Groups - TrustEL Architecture v01.pdf uploaded

 

Submitter's message
The linked powerpoint deck is for this week's Trust Elevation TC call to discuss TE Protocol models and architecture for the 4th Deliverable.
Andrew Hughes
-- Andrew Hughes

Document Name: TrustEL Architecture v01.pdf


Description
Slides for discussing protocol models and architecture
Download Latest Revision
Public Download Link


Submitter: Andrew Hughes
Group: OASIS Electronic Identity Credential Trust Elevation Methods (Trust Elevation) TC
Folder: Working Documents
Date submitted: 2015-01-20 08:34:18

 

 

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]