[Specs-cx] Even RP can provide CX Templates( Re: Discovery process )

[nara hideki]

Thanks, shall we state how to verify the template ?
MAC digest is not enough for the proof of the ownership as you
mentioned the signature. But the signature rule for a template has not
been described.

Do you think if a template should be a structured format file which
can be digitally signed like CX Contract XML ?

----
hdknr.com

2010/4/14 Nat Sakimura <sakimura at gmail.com>:
> Yes. Conceptually, anybody can publish template. It is only when
> subjects are filled and signed, it starts to have meaning.
>
> Best,
>
> =nat
>
> On Wed, Apr 14, 2010 at 2:59 PM, nara hideki <hdknr at ic-tact.co.jp> wrote:
>> Hi,all
>>
>> =Nat told me that RPs can provide CX Template.
>> Even more , any body can provide templates if those are not fake.
>> It sounds reasonable.
>>
>> 2010/4/12 nara hideki <hdknr at ic-tact.co.jp>:
>>> Hi, all
>>>
>>> I'm thinking of the CX discovery process.  Any suggestion is welcome to correct.
>>>
>>> 1.  Discover by Server Identifier.
>>>
>>> Because CX Service and its contract is quite specific and dependent
>>> on an OP,  a RP must have already known
>>> the service and its contract detail and offer end users to click to
>>> use the service.
>>> So discoveries are requested with the server identifiers of which  OP
>>> provider the corresponding service.
>>>
>>> 2. For XRDS, find  XRD/Service/Type for the specific CX Service.
>>>
>>> Fictional Google's contract-based attribute exchange service can be
>>> discovered with the following XRDS::
>>>
>>> <?xml version="1.0" encoding="UTF-8"?>
>>> <XRDS>
>>>  <XRD>
>>>  <Service priority="0">
>>>  <Type id="10" >http://specs.openid.net/auth/2.0/server</Type>
>>>  <Type id="20" >http://openid.net/srv/ax/1.0</Type>
>>>  <Type id="30" >http://openid.net/srv/cx/1.0/#</Type>
>>>  <Type id="40"
>>>>https://www.google.com/accounts/o8/cx/attribute_exchange.txt?sha256=c8d6c46425bf83b6eebcf9fb24ac5ff7599e97f7b24973e53ae114a1a072ec67</URI>
>>>  <URI>https://www.google.com/accounts/o8/ud</URI>
>>>  </Service>
>>>  </XRD>
>>> </XRDS>
>>>
>>> where, Type/@id=30 means this Service endpoint provides an OpenID CX
>>> protocol and
>>> Type/@id=40 means it also provides a "contract-based attribute exchange" .
>>>
>>> 3. RP composes a proposal  with this URL for the contract
>>>
>>> RP may compose the following Contract XML for CX proposal and send it
>>> the OP endpoint.
>>>
>>>  <Contract>
>>>    <Type>http://openid.net/srv/cx/1.0/#proposal</Type>
>>>    <Party>
>>>        <URL>http://yoursocial.com</URL>
>>>        <Rel>http://openid.net/srv/cx/1.0/#proposer</Rel>
>>>        <obligations>
>>>            <param type="http://axschema.org/namePerson/first"
>>> id="first_name"></param>
>>>            <param type="http://axschema.org/namePerson/last"
>>> id="last_name"></param>
>>>            <param type="http://axschema.org/contact/email" id="email"></param>
>>>        </obligations>
>>>        <Service>
>>>               <Type>https://www.google.com/accounts/o8/cx/attribute_exchange.txt?sha256=c8d6c46425bf83b6eebcf9fb24ac5ff7599e97f7b24973e53ae114a1a072ec67</Type>
>>>                <URL>https://www.google.com/accounts/o8/ud</URL>
>>>        </Service>
>>>    </Party>
>>>    <Template>
>>>       <!--- here is  the base64 encode version of the CX Template
>>> requested by
>>>           /Contract/Party/Service/Type --->
>>>    </Template>
>>> </Contract>
>>>
>>>  Service element looks verbose, but there should be because this
>>> document must be proof of  what all parties has aggreed
>>> and reduces another discovery process later.
>>>
>>> ----
>>> hdknr
>>>
>> _______________________________________________
>> Specs-cx mailing list
>> Specs-cx at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-cx
>>
>
>
>
> --
> Nat Sakimura (=nat)
> http://www.sakimura.org/en/
> http://twitter.com/_nat_en
>