Is there an argument for following the SREG pattern of putting it in the request.
Other than the RP perhaps not publishing a XRDS for some reason. (if they don't do that they are not that likely to publish a privacy policy ether.)
While we are at it do we want to also publish a TOS URI? John B. On 2009-11-13, at 9:28 PM, Breno de Medeiros wrote:
s/legal/privacy/gOn Fri, Nov 13, 2009 at 4:28 PM, Breno de Medeiros <[email protected]> wrote:Keeping the requests short is a Good Thing, but I have heard argumentsthat showing a legal policy from an untrusted source A and claiming that it is the policy of party B (remember that the request could be forged) could be a non-starter for some OPs.On Fri, Nov 13, 2009 at 4:24 PM, John Bradley <[email protected] > wrote:That could easily be done via a new element in the XRDS. That requires RPdiscovery, not a bad thing. You are thinking about keeping the request size down? John B. On 2009-11-13, at 8:22 PM, Allen Tom wrote:Agreed - it would be great if we could make the RP's privacy policy URLdiscoverable. Allen Breno de Medeiros wrote: +1 and also a vote for the spec to define a URL which can be used to publish the policy URL in the XRD(S) document as well.On Thu, Nov 12, 2009 at 8:42 PM, Allen Tom <[email protected]> wrote:+1Definitely would love to see AX 1.1 released, hopefully eliminating any needfor SREG.To reach parity with SREG, AX 1.1 needs to have a standard way for RPs to pass their privacy policy URL, and it would be great to have a standardschema with very short attribute names.It's very costly for OPs (and RPs) to support dual SREG and AX interfaces, when only one interface is necessary. It also hurts the interop story if there's no standard and widely implemented way to share basic profile data.Allen Dick Hardt wrote: +1! On 2009-11-12, at 8:05 AM, Nat Sakimura wrote: Hi.In anticipation of the Working Group creation process gets simplified in a couple of days, I have edited AX charter proposal to add "1.1" for a quick fix of things like privacy policy url and fetch parameters, which requires only few lines of additions, so that we can finish it quickly and then workmore substantial 2.0, which includes the data structure change.Also I have created Artifact Binding Charter, which will allow the use of OpenID in limited browsers (e.g., mobile) and improves security. Please feelfree to add your names to the list of proposers. Best, -- Nat Sakimura (=nat) http://www.sakimura.org/en/ _______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs ________________________________ _______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs _______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs _______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs-- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7)-- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7)
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
