Hi,<br><br>And log aggregation could be.  <br>We can think of logs as the other protected resource. <br>But some meta data should be defined to link logs to each contracts and access tokens.<br><br><div class="gmail_quote">
2011/10/26 Nat Sakimura <span dir="ltr"><<a href="mailto:sakimura@gmail.com">sakimura@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
<br><div class="gmail_quote"><div class="im">On Wed, Oct 26, 2011 at 4:31 AM, hideki nara <span dir="ltr"><<a href="mailto:hdknr@ic-tact.co.jp" target="_blank">hdknr@ic-tact.co.jp</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Topics can be the followings:<br><br> - Multiple tokens for a single Connect session :  may be covered in "to define the claims structure only".<br></blockquote><div><br></div></div><div>Is it not covered by the distributed claim response of UserInfo endpoint? </div>
<div class="im">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> - Token validation by  the Protected Resources other than OAuth Servers : UMA may cover this.<br></blockquote>

<div><br></div></div><div>Probably yes. It should leverage on JWT and asymmetric crypto. </div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

 - Delegations(?) ( Delivering access tokens to Clients other than RP which initiates a Connect session )<br></blockquote><div><br></div></div><div>Asymmetrically encrypted access token, I suppose. </div><div>Need to define them. I guess UMA would also need it. </div>
<div class="im">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> - Notification..<br><br>Any others ?<br></blockquote><div><br></div></div><div>I think these requirements cover pretty well.  </div>
<div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">--<br>hdknr<br><br><div class="gmail_quote">2011/10/22 Nat Sakimura <span dir="ltr"><<a href="mailto:sakimura@gmail.com" target="_blank">sakimura@gmail.com</a>></span><br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div></div><div>So, much of the earlier Contract Exchange work (underlying protocol) were taken up by the new Connect protocol. <div>

This means that the remaining bit of things that this working group has to do is to define the claims structure only, which is good. </div>

<div>In the past, we have been talking about it in XML but as Connect is completely JSON based, perhaps we should try to convert it to JSON as well. </div><div><br></div><div>It should not be too difficult to do. </div><div>



<br></div><div>Also, there are related protocols like open-transact being proposed elsewhere. Perhaps we shall look at it as well. </div><div><br></div><div>Thoughts? <br clear="all"><font color="#888888"><div><br></div>


-- <br>Nat Sakimura (=nat)<div>
Chairman, OpenID Foundation<br><a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>@_nat_en</div><br>
</font></div>
<br></div></div>_______________________________________________<br>
Specs-cx mailing list<br>
<a href="mailto:Specs-cx@lists.openid.net" target="_blank">Specs-cx@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-cx" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-cx</a><br>
<br></blockquote></div><br>
</blockquote></div></div><div><div></div><div class="h5"><br><br clear="all"><div><br></div>-- <br>Nat Sakimura (=nat)<div>Chairman, OpenID Foundation<br><a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>
@_nat_en</div><br>
</div></div></blockquote></div><br>