RE: [orms] Minutes of the 6/16/2010 meeting.

["Mani, Mahalingam (Mani)" <mmani@avaya.com>]

On cert-profiling:

Perhaps profiling (of certificates) is too strong a term to use. Some guidance on the characteristics of such a signing is what I was driving towards - in order to provide a verifiable binding between the reputer/reputor's identity (as organization or individual or delegated-signing by an organization/vendor/social-network/some-community) and the reputation-assertion.

In some cases - such a signing may be inconsequential/optional depending on the domain of assertion (e.g., being local to the domain of the consumer of assertion).

I will fix the extensibility minutes based on your corrections - I agree - thanks.

-mani
-----Original Message-----
From: Tatsuki Sakushima [mailto:tatsuki@nri.com] 
Sent: Thursday, June 17, 2010 1:10 PM
To: orms@lists.oasis-open.org
Subject: Re: [orms] Minutes of the 6/16/2010 meeting.

Hi Mani


My comments are inline:


(6/17/10 12:20 PM), Mani, Mahalingam (Mani) wrote:
> Attendees: Nat, Tatsuki, Mani
>
> Quorum: Yes.
>
> Minute-taker: Mani
>
> Approved: the minutes of the last (quorum’ed) meeting
>
> 1. Tatsuki Explained the document updates made by Tatsuki.
>
> 2. Nat questioned the scope/extent of extensibility
>
> a. Tatsuki: new XML elements can be added to the doc. Namespace is
> extensible.
>

The current draft doesn't specify the extension mechanism in a XML way.
Instead, it provides the <Context> element as "reputation namespace"
for data providers (we need a proper term for this one too) to define
the semantic of data and attributes in <Score> and <Data>.

Adding the XML namespace and extensibility is still TBD.


> 3. Nat asked that reputer element be added to the reputation definition
> in the XML reputation doc.
>
> a. It was also agreed that reputer’s identity and reputation information
> should be accessible from there.
>
> b. Mani: The reputation element is signed by reputer. Nat agrees.
>
> c. Nat: the reputation-bundle itself is signed by bundling reputer.
>

Digital signing is one way to say who is a reputor.
Providing a vaule in the <Reputor> element is another.
The value type in the <Reputor> is TBD. It should be any string IMHO.
Amazon doesn't use URIs to identify their users. It's a mail address
or handle name their users define.

In a casual use cases, the value should allow some flexibility.
What should be in the value is up to use cases. The spec can not define.
  
> [Mani – post-meeting query]: do we need to specify the (signing)
> identity certificate’s profile? And the signature’s encapsulation
> requirements?
>

I wasn't expecting profiling works in this TC.
If we consider the current resource and time we can spend on this,
extending our work to "profiles" is a bit cumbersome.

> 4. Reference model: Mani raised questions about any updates needed to
> reference model in light of the draft evolution?
>
> a. Mani to review the need for any. Tatsuki mentions that all aspects
> are still consistent with reference model in the prior reference document.
>
> b. Mani: A simplified OASIS-ised depiction of the generalized reference
> model focused on the charter and goals of the TC would still be relevant.
>

I agree on simpliying it and make it more relevant to the draft.
Also the terminology section and the reference model should be
well coordinated.

Best,

Tatsuki


PLEASE READ：This e-mail is confidential and intended for the named recipient only.
If you are not an intended recipient, please notify the sender and delete this e-mail.

> Regards,
>
> -mani
>
> =============
>
> Mahalingam Mani
>
> 408.321.4840 (w)
>

---------------------------------------------------------------------
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

smime.p7s