... for the rechartering. <div><br></div><div>As I see, Standard label &quot;protocol&quot; has three maturity phases. </div><div><br></div><div>ph.1 - Just a text / graphical display. Human readable, but not quite machine readable. </div>
<div>ph.2 - Machine readable structured data version. In this case, the multi-lingual support becomes trivial. </div><div>ph.3 - Auto-negotiation between the client and the server. The authorization server / user-agent </div>
<div> stores the user preference and judges if the request falls into &quot;ok&quot; or &quot;ask&quot; category. </div><div> In the later case, the user will be prompted to review and give consent. </div><div><br></div><div>
>From the operational point of view, the labels have to be stored at a trusted archive. </div><div>Otherwise, the client may launch an attack to the users by changing the labels and saying </div><div>that it was like that all the time and the user gave consent to it. </div>
<div><br></div><div>For this reason, it may be a good practice to have a trusted repository in which the labels are stored, </div><div>and the IdP or Apps pulling the label from the repository to show it to the user. </div>
<div>In case of IdP, the IdP can store the fact that the user gave consent at such and such time, </div><div>so that it can be compared to the repository. </div><div>In case of an App that wants to pull the data from the device, it gets more challenging. </div>
<div>It is probably better to have a local IdP and the Apps to interact with it, </div><div>but it is a long way to go. <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>
</div>