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

 


Help: OASIS Mailing Lists Help | MarkMail Help

orms message

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


Subject: [orms] Minute 4/8 - ORMS TC Bi-weekly telecon


ORMS TC Bi-weekly telecon has been modified by Mr. Nat Sakimura
 
Date:  Thursday, 8 April 2010
Time:  15:00pm - 16:00am PDT
 
Attending:

John Bradley
Corey Leong
Mani Mahalingam
Nat Sakimura
Tatsuki Sakushima

Discussions:

Nat encourages again that TC members update "Real world use cases" in Wiki, especially region specific ones.

Nat suggests using ORMS format in order to express "level of assurance" discussed in US government ICAM, 
Federal Identity, Credential, and Access Management because certification is one of extreme way to state IDP's reputation.

John explain that LOA certificaition information is inserted into a SAML metadata signed by a federation operator. 
This could be conjunction of ORMS and LOA.
Nat raises another point, level of protection(privacy?). In Japan, 90% of people want some level of privacy protection
of the data provided to RPs. This should be considered as well.

Mani asks John there is any transaction compornents. He tries to capture them and write them up in wiki.

To discuss about aggregation of sub data, TC does not reach conclusion. If TC wants to add hierarchy to the data format,
data distribution topology and transportation mechanism should be discussed further.

TC discusses about "Rank" again but needs to discuss further about definition of "Rank".


Tatsuki Sakushima
NRI Pacific - Nomura Research Institute America, Inc.
TEL:(650)638-7258
SkypeIn:(650)209-4811

(3/24/10 6:13 PM), Tatsuki Sakushima wrote:
> ORMS TC Bi-weekly telecon has been modified by Mr. Nat Sakimura
> 
> Date:  Thursday, 25 March 2010
> Time:  07:00am - 08:00am JST
> 
> Attending:
> 
> Henrik Biering
> Corey Leong
> Mani Mahalingam
> Nat Sakimura
> Tatsuki Sakushima
> 
> Dee Schur (Special guest from OASIS)
> 
> Selection of a Secretary for this meeting:
> 
> Tatsuki volunteered for this call.
> Approval of the minute from the last meeting:
> 
> Approved.
> 
> Discussions:
> 
> 1. Link element in the reputation format:
> 
> Nat explains the motivation for adding multiple "link" elements to 
> express multiple reputations. On Working draft wiki page, 5.2 Reputaton 
> Response section, we have only one single reputaiton response but we can 
> in concept have multipule reputation outputs. For example, Grading a 
> camera can be split into one overall grade (A+) and sub grades (size, 
> style, image clarity etc).
> 
> Mani asks that link elements are in the same reputation context and 
> expresses about the same entity. Nat continues to explain and the answer 
> is yes. Mani also raises the point that splitting reputation data to 
> multiple files would help access control of certain data.
> 
> Mani asks an example of use cases for multi-vector/context.
> (Probably we need discuss about definition of "context" and "vector".)
> 
> Nat also advocates link structure to aggregate multiple reputation data 
> in one file and emphasizes this way will simplify signature processing. 
> Tatsuki raises the point that this case it will need to use some kind of 
> type URL to express what kind of data is in the link. And Nat suggests 
> relationship (at least child and parent) types.
> 
> Corey asks an example of markup language does similar. Tatsuki thinks 
> that XRD has a similar structure. Nat thinks HTML5 Link structure is 
> also the same.
> 
> Mani thinks that the link structure might bring some complexity in 
> implementation and interoperability issues.
> Tatsuki thinks that making the link element optional in syntax would 
> solve complexity and interoperability issues.
> 
> Bill is an original advocate for multiple-reputation, so TC decides to 
> differ a final decision until he comes back.
> 
> Nat will come up with an example of how the "link" element will be use 
> aggregate multiple reputation data in the ML for further discussion.
> 
> 2. Applying signature matters
> 
> Nat considers to use XMLSig with exclusive-c14n.
> 
> 
> 3. What data should be in the reputation XML(format)
> 
> Nat thinks that this is not finalized and needs further discussion.
> Nat comes up new ideas, the "link" structure discussed above and "rank" 
> and he encourages other members to add.
> Nat thinks that ranking data would be useful for popularity of products 
> and so forth. Mani asks that ranking is output of some normalization or 
> sort of function of score. Nat brings rank as an idea. Tatsuki thinks 
> that ranking is a type of score and can be express it as a type of score 
> not has to be separate data element. Nat points out that definition of 
> "score" in the current WG is a statistical value. It is not covering 
> data like ranking. Tatsuki concerns that adding data elements this way 
> would result blown up to too many of them. Tatsuki suggests making score 
> as "class" or "model" so it can be instantiate with specific type 
> information which express what the score stands for.
> 
> TC probably needs further discussion about how to express score in the 
> format. One overall data in the format and multiples with links. Score 
> and Rank in the same format? Look at use cases individually and figure 
> out the best way to accommodate all use cases.
> 
> Tatsuki thinks that how we design the format depends on design 
> principles. Simplicity v.s. Extendability. Tatsuki leans to simplicity 
> over extendability because he thinks interoperability is a key for 
> adoption. More extendability usually brings more issues on 
> interoperability. If the score is more conceptualized, score needs meta 
> data for "scale" and how to express (in numbers) For example, 5 stars (5 
> scales) for products in Amazon. 6?0 to 830 (range) for FICO score etc.
> 
> Nat asks Tatsuki to elaborate his idea further and post is in ML.
> 
> 4. Outreach
> 
> Dee asks TC members to give her more information (especially use cases) 
> so she can use them to outreach other members who should join this TC.
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php


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