AX and Artifact Binding Charter Proposal

Breno de Medeiros breno at google.com
Sat Nov 14 00:28:01 UTC 2009


Keeping the requests short is a Good Thing, but I have heard arguments
that 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 <john.bradley at wingaa.com> wrote:
> That could easily be done via a new element in the XRDS.  That requires RP
> discovery, 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 URL
> discoverable.
>
> 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 <atom at yahoo-inc.com> wrote:
>
>
> +1
>
> Definitely would love to see AX 1.1 released, hopefully eliminating any need
> for 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 standard
> schema 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 work
> more 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 feel
> free to add your names to the list of proposers.
> Best,
>
> --
> Nat Sakimura (=nat)
> http://www.sakimura.org/en/
> _______________________________________________
> specs mailing list
> specs at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
>
> ________________________________
> _______________________________________________
> specs mailing list
> specs at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
>
>
> _______________________________________________
> specs mailing list
> specs at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
>
>
>
>
>
>
> _______________________________________________
> specs mailing list
> specs at lists.openid.net
> 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)


More information about the specs mailing list