Re: [orms] 2008-05-02 Mtg Minutes (plain text)

[=JeffH <Jeff.Hodges@neustar.biz>]

ORMS TC Minutes
2nd May 2008 (continued from previous day's meeting)
Scribe: Bill Barnhill

Minute taker: Bill Barnhill

5 Review of the TC charter -- the statement of purpose, goals, deliverables, 
schedule, etc.

5a. Drummond Reed's proposed changes (sent to mailing list)
Bill Barnhill moved to adopt Drummond's charter change
Hal seconded
Approved without objection

5b. Bill Barnhill's proposed changes (sent to list via Drummond)
Discussion of meaning of score(s). Position noted by Tony Natalin and Nat 
Sakamura that they feel   the proposed change broadens the scope.

Hal made motion to amend 'assessment' to 'rating', not seconded

Chris made motion to amend assessment to 'calculation'
.Seconded by Hal

Hal read the section on clarifying vs expanding the scope

Jeff H. noted contextual identifiers may be output

Chris, Daniella noted that contextual identifiers may be covered under relevancy

Jeff noted the assessment word occurs multiple times, so calcultion would need 
to  replace it in several locations.

Chris clarified his amendment that it be changed in all three places

Hal seconded it

Tony, asked if discussion finished and asked if anyone opposed to the 
amendment, calling the question.

Tony clarified that this was only the amendment to change the word assessment 
to calculation in the proposed new charter text, not a vote to adopt the 
proposed changes to the charter.

No objections, amendment passes.

Now voting on accepting changes to the charter text,. Tony asked for objections.

Tony and Nat made objections,

Hal made motion to table this motion and submit the amended text to TC admin 
for an advisory opinion as to whether this would constitute a clarification or 
a scope change.

Seconded by Chris.

Hal noted we can take action after we get advice if we table it for now.
Hal restated his motion: Table the motion and submit

Tony: Calling the question on tabling.

3 objections: Les, Jeff, Frank

Motion to table until after we get advice passed, so it will be sent to OASIS 
for advice.

Tony asked if there were any objections to accepting other changes (Drummonds), 
no objections.

So discussion moved to Use cases.

7. Go over Possible Usecases & Scenarios
Daniella went over her slide deck, noted it will be contributed to TC document 
area in PDF form.

Chris then went over his slides:

Peter asked Chris: Sounds like you're defining defining space to be relevant inputs
Chris agreed.

Peter: Relying party is the one that's defining this space. So it's 
interesting, is the RP defining the space or is the OP defining the space

Nat noted if you calculate a score it doesn't become a reputation until you 
publish it

Peter: Definition of context is what's really important. Context of the 
aggregate result  is what we're really getting at.

Reputation evaluation is going to be based on my particular context.

Jeff: If you take the model that's in the XACML then the policy decision 
process is well defined.

Hal: When you get the score you need to get the inputs that were used to create 
the score. In some circumstances knowing the output and all the inputs would 
allow you to reverse engineer the algorithm

Note (Bill): Addressing all the inputs may involve considerations of privacy, 
if you give someone a negative vote will they know?

Chris then continued with slides

Peter: To a great extent all the statements on Chri's slides are related to the 
verifiability of the claim.

Chris: Correct

Peter: Seems very related to PEP (Policy Enforcement).  System that gets 
reputation score as input, never mind what it's doing with it's data. 
Expectation is output will be a policy decision.

Bill: WS-Policy analogy, using custom assertions ie Trusted

Hal: (ref: Bill's analogy) Not how I see WS-Policy working
Hal: On slide 4 are you saying the stuff outside box, policy is what we're 
trying to address?
Jeff: No
Hal: In which case I may not disagree. My interest is what's in the box

Drummond: What I was seeing was that you could take a bunch of these boxes and 
connect the outputs
Bill: Reputation pipelines

Peter: Use case that was described was really about inputs to a PDP. How I 
actually tell the inputs that they're wrong is something different. I think we 
need to solve that, but it's something different.   The context  is about 
controlling the inputs as a RP..the context may be pictorial outside the 
defining space.  The RP can dictate some of the inputs to the algorithm.

JJ? : In it's simplest form the inputs might just be weights.

Peter:  Scoping question: Do we care whether an RP can tell the algorithm what 
to do?
I can either tell Ebay to give me a #, or I can tell Ebay to give me only the 
number  coming from these users.

Peter: So the question is whether the RP gets some kind of dynamic set of 
inputs to the algorithm  or whether it will be static inputs.

Jeff: The weights are Historesis (ref control theory, and check spelling) aka 
feedback to the algorithm.

Chris: Essentially this is personalizing the algorithm.

AI for Bill: Write up his use cases in a doc and publish to ORMS TC docs.

AI for Bill: Work with OASIS TC Staff to fix permissions on TC Doc uploading

Nat: Anything more to discuss on slide 4?

No one said.

Nat: Next time we really need to define reputation.

Peter: I think the input of the producer or the defining space is a policy 
information point with respect to the relying party,  Most of the use cases are 
relevant to inputs into a policy decision.  An example is a linkedin invitation 
to join a social graph, and I look at their links to decide whether to include 
them.

Bill: Have we clarified that trust and reputation are two separate things?

Jeff, ?: No, and that's something we really need to do. I would say we need to 
generate a UML reference model and we shouldn't invent it out of whole cloth.

Jeff: Wiki is poor tool for hacking on documents. But great tool for publishing 
stuff.

Peter: Some combination of email and wiki will be used for terminology.

Nat: Who's leading terminology work?

Jeff H: I'll  do it.

Nat: Something by next week. Perhaps have strawman of the list of terms to define.

Terms we need to define, strawman: Context, Score, Reputation, Defining space, 
Input,       domain,   reputee, reputer

If we have definitions that we've come up with then we should email Jeff H with 
them.

May have an adhoc meeting, no decisions as no quorum, at IIW.

Nat: If you have any input to the TC please submit it.

Peter: First real work will be a use case document.

AI[Bill]: Check with Mary if there is a template for a Use Cases document

AI[Bill]: Come up with Use case template document by next week, but not fitting 
everything in by next week.

Nat presented slides of his presentation:

Nat: We don't want our model to be too much of a moving target

Bill: True, and we also don't want to go the other way by defining too 
stationary or rigid a target or we risk alienating a large portion of our 
potential adoption audience

Dorothy: Input variables should be user defined.  It's important to keep in 
mind the capability to represent subjective inputs.

Need to include what meaning of value is.

Chris: Degree of uncertainty needs to be captured.

Jeff: Confidence level as seen by the provider, and confidence level as seen by 
the reputer.

Chris moved to adjourn, Drummond seconded.

---
end