OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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+VW5pcXVlX2lkZW50aWZpZXI8L0Nhbm9uaWNhbElEPg0KICA8U2lnbmVy
> SUQ+VW5pcXVlX2lkZW50aWZpZXI8L1NpZ25lcklEPg0KICA8U2VydmljZT4NCiAgICA8UHJvdmlk
> ZXJJRD5odHRwczovL2V4YW1wbGUuY29tL3NlcnZlciMxNDIzNTQzNTY3MjwvUHJvdmlkZXJJRD4N
> CiAgICA8VHlwZT5odHRwOi8vc3BlY3Mub3BlbmlkLm5ldC9hdXRoLzIuMC9zaWdub248L1R5cGU+
> DQogICAgPFR5cGU+aHR0cDovL3NwZWNzLm9wZW5pZC5uZXQvdHgvMS4wPC9UeXBlPg0KICAgIDxV
> Ukk+aHR0cHM6Ly9leGFtcGxlLmNvbS9zZXJ2ZXI8L1VSST4NCiAgPC9TZXJ2aWNlPg0KICA8U2Vy
> dmljZT4NCiAgICA8UHJvdmlkZXJJRD5odHRwczovL3N0cy5lcXVpZmF4LmNvbS8jMjAwODEyMDMw
> MDAwMDA8L1Byb3ZpZGVySUQ+DQogICAgPFR5cGU+aHR0cDovL3NjaGVtYXMuaW5mb3JtYXRpb25j
> YXJkLm5ldC9AaWNzL2FnZS0xOC1vci1vdmVyLzIwMDgtMTE8L1R5cGU+DQogICAgPFVSST5odHRw
> 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
>
> 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]