RE: [xri] SimpleSign Inline Mode and Base64

["Drummond Reed" <drummond.reed@cordance.net>]

Nat, my apologies, I meant the payload. So we'd call the child element
whatever was appropriate, such as <Data> or <Base64>.

=Drummond 

> -----Original Message-----
> From: Nat Sakimura [mailto:n-sakimura@nri.co.jp]
> Sent: Thursday, January 22, 2009 3:01 AM
> To: Drummond Reed; 'John Bradley'; 'George Fletcher'
> Cc: 'XRI TC'
> Subject: Re: [xri] SimpleSign Inline Mode and Base64
> 
> We have just started to check the library implementation of Base64 in
> various languages.
> I will not get the result by tomorrow morning, but will keep you posted as
> soon as I get it.
> 
> Drummond: we are not talking about the signature. We are talking about the
> payload itself.
> 
> =nat
> 
> --------------------------------------------------
> From: "Drummond Reed" <drummond.reed@cordance.net>
> Sent: Thursday, January 22, 2009 3:18 PM
> To: "'John Bradley'" <jbradley@mac.com>; "'George Fletcher'"
> <george.fletcher@corp.aol.com>
> Cc: "Sakimura Nat" <n-sakimura@nri.co.jp>; "'XRI TC'"
> <xri@lists.oasis-open.org>
> Subject: RE: [xri] SimpleSign Inline Mode and Base64
> 
> > +1 to staying away from allowing mixed content in the XRD element. If
> > base64 encoding means it's better to use an element than an attribute,
> > then why not dedicate a child element to that purpose? If there's no
> > signature, this child element is absent (or ignored if present). If
> there's
> > a signature, it's in that element.
> >
> > <XRD sig="signature" sigalg="http://www.w3.org/2000/09/xmldsig#rsa-sha1";
> > certuri="pem file location" >
> >            <SigValue>{BASE64 of the payload}</SigValue>
> > </XRD>
> >
> > =Drummond
> >
> > ________________________________
> > From: John Bradley [mailto:jbradley@mac.com]
> > Sent: Wednesday, January 21, 2009 8:18 AM
> > To: George Fletcher
> > Cc: Nat Sakimura; XRI TC
> > Subject: Re: [xri] SimpleSign Inline Mode and Base64
> >
> > I don't think that using post will be a common use case for passing XRDs
> > but you never know.  If they are signed it is possible someone will come
> > up with a reason to do it.  Perhaps for some sort of user directed
> > discovery?
> >
> > I agree with George that making the base64 the content is a bit weird.
> I
> > am leaning towards attribute to keep it simple.
> > That way the content can be the decoded XML for readability if desired.
> >
> > =jbradley
> >
> > On 21-Jan-09, at 12:51 PM, George Fletcher wrote:
> >
> >
> > The base64 tools I've used recently don't default to wrapping at 76
> > chars, though I did see that this is the default for GNU coreutils.
> > However, there is an option to not wrap. For sure, browsers can wrap
> > base64 encoded content when submitting a form (as this affected the
> > original SAML SimpleSign spec) but since the XRD is more focused around
> > a file format I don't see this being an issue. Are there use cases where
> > XRD's are POST'd to endpoints using the HTTP POST re-direct method?
> >
> > That said, if experience shows it's easier to treat the base64 data as
> > content of the element rather than an attribute I'm ok with that.
> >
> > One final question, if we do make it content of the element, won't that
> > make the XRD schema a little weird? The XRD could contain direct content
> > OR other elements if not using the "Inline mode".
> >
> > Thanks,
> > George
> >
> > Nat Sakimura wrote:
> >
> >
> > In http://wiki.oasis-open.org/xri/XrdOne/SimpleSign, I have changed
> > the name
> > "Wrapped mode" to "Inline Mode" since I dropped the wrapper.
> >
> > Now, it is like George suggested.
> >
> > <XRD sig="signature" sigalg="http://www.w3.org/2000/09/xmldsig#rsa-sha1";
> > certuri="pem file location" data="BASE64 of the payload" />
> >
> > When I was talking about this with Masaki, he suggested that since
> BASE64
> > usually
> > wraps at 76 or less characters per line, doing it like:
> >
> >
> > <XRD sig="signature" sigalg="http://www.w3.org/2000/09/xmldsig#rsa-sha1";
> > certuri="pem file location" mode="inline">
> >
> ICA8Q2Fub25pY2FsSUQ+VW5pcXVlX2lkZW50aWZpZXI8L0Nhbm9uaWNhbElEPg0KICA8U2lnbm
> Vy
> >
> SUQ+VW5pcXVlX2lkZW50aWZpZXI8L1NpZ25lcklEPg0KICA8U2VydmljZT4NCiAgICA8UHJvdm
> lk
> >
> ZXJJRD5odHRwczovL2V4YW1wbGUuY29tL3NlcnZlciMxNDIzNTQzNTY3MjwvUHJvdmlkZXJJRD
> 4N
> >
> CiAgICA8VHlwZT5odHRwOi8vc3BlY3Mub3BlbmlkLm5ldC9hdXRoLzIuMC9zaWdub248L1R5cG
> U+
> >
> DQogICAgPFR5cGU+aHR0cDovL3NwZWNzLm9wZW5pZC5uZXQvdHgvMS4wPC9UeXBlPg0KICAgID
> xV
> >
> Ukk+aHR0cHM6Ly9leGFtcGxlLmNvbS9zZXJ2ZXI8L1VSST4NCiAgPC9TZXJ2aWNlPg0KICA8U2
> Vy
> >
> dmljZT4NCiAgICA8UHJvdmlkZXJJRD5odHRwczovL3N0cy5lcXVpZmF4LmNvbS8jMjAwODEyMD
> Mw
> >
> MDAwMDA8L1Byb3ZpZGVySUQ+DQogICAgPFR5cGU+aHR0cDovL3NjaGVtYXMuaW5mb3JtYXRpb2
> 5j
> >
> YXJkLm5ldC9AaWNzL2FnZS0xOC1vci1vdmVyLzIwMDgtMTE8L1R5cGU+DQogICAgPFVSST5odH
> Rw
> > czovL3N0cy5lcXVpZmF4LmNvbS88L1VSST4NCiAgPC9TZXJ2aWNlPg==
> > </XRD>
> >
> > Which do you think is better?
> >
> > Any opinion?
> >
> > =nat
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the OASIS TC that
> > generates this mail. Follow this link to all your TCs in OASIS at:
> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the OASIS TC that
> > generates this mail.  Follow this link to all your TCs in OASIS at:
> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php