Minute 4/21 - ORMS TC Bi-weekly telecon

[Tatsuki Sakushima <tatsuki@nri.com>]

ORMS TC Bi-weekly telecon has been modified by Mr. Nat Sakimura

Date:  Thursday, 21 April 2010
Time:  15:00pm - 16:00am PDT

Attending:

John Bradley
Mani Mahalingam
Nat Sakimura
Tatsuki Sakushima

Discussions:

0. Minute

The minute of the last telecon was approved.

1. Transport Mechanism

John provides the recap of his point from the last call. Without a wrapper container, it is going to end up with explicit links to each element to every other element etc. It should be transport independent. The wrapper container can keep relation between ORMS files. If the use case is handling multiple sources for reputation and all those are gathered as a response, a wrapper container should be required. Relationship like reputation A referring to reputation B should be defined separating from transport mechanism like http link etc otherwise it can only work with retrieving via http. URI should be used as an identifier of the referred file as well as a address. The container rule will be like link rel address (URI) found, check if it match with the value of the Subject.

As the solution, Nat suggests that XRDS stick each reputation file together into a single file, so ...(lots of noise I could not capture).

John also mentions that this way is more efficient for processing internally without generating http GET to fetch sub reputation files from a master reputation file. 

2. reputation file only relative to package or globally unique for "referred in"?

Nat answered John's question above, it should be globally unique because it is feasible to do it if it has full URI. John points out that giving out globally unique address to everyone leads to privacy issues by correlating data with the address. Subject of reputation should be anonymous to disclose reputation without disclosing too much identity. If someone discloses reputation to multiple locations, each has a different identifier. SAML's transient NameID and PPID are examples of such a identifier.

If these packets of information is part of a bearer token, the identifier has scope of that transaction, being global unique as long as we limit the scope is differable. The subject of the reputation in time A is different from the subject of the reputation in time B. The identifier of reputation file should be changed in a different transaction by using global unique identifier.

3. Subject Identifier

Mani asks what would happen when transporting reputation score as metadata of SAML attribute between two systems with entities' identifiers. Making reputation correlatable or not depends on a site's preference. So, we should provide the control to users.

Nat points out that we might want to leverage on underline assertion types and identifiers in it. When he wants to carry his reputation to a site that has his PPID, it won't be useful if the ID in the reputation file is not the same as the ID in the authentication assertion. John answers that it is up to RP to correlate them with a bearer token. Nat points out that from time to time we might want to compre how the reputation has been changed about the subject. Because this is intertime correlation, this can be done by reputation consumer not internal identifiers. Nat prefers using session unique identifiers for reputation subject so that it makes easier to control.

John points out that we are going to have multiple subjects because each of sub reputation bundle will have own subject. The subject is reputation itself not a person. The subject is reputation of property of subject such as attributes or assertions. Adding "subject" definition  on reputation layer to terminology might be useful.

Mani volunteers writing up today's topics about transport, format, identifier for continuing further discussion in ML. 

John also suggests using the same identifier type for all kinds of subjects in order to avoid complexity and interoperability issues.

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