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


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'm not sure I like "the content can be the decoded XML for  
readability if desired." Seems like it wouldn't really help with  
debugging, except for when you're sure you're codecing Base64  
correctly, at which point it's not a big deal to just have the  
Base64. Which then makes having the data as a child element unnecessary.

So long as the doc doesn't contain both the plaintext and encoded  
data, only one of which is authoritative, I'll be happy with whatever  
colour bikeshed.

http://josephholsten.com

On Jan 22, 2009, at 9:57 AM, Drummond Reed wrote:

> 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 
>> +VW5pcXVlX2lkZW50aWZpZXI8L1NpZ25lcklEPg0KICA8U2VydmljZT4NCiAgICA8UHJv 
>> dm
>> lk
>>>
>> ZXJJRD5odHRwczovL2V4YW1wbGUuY29tL3NlcnZlciMxNDIzNTQzNTY3MjwvUHJvdmlkZ 
>> XJJRD
>> 4N
>>>
>> CiAgICA8VHlwZT5odHRwOi8vc3BlY3Mub3BlbmlkLm5ldC9hdXRoLzIuMC9zaWdub248L 
>> 1R5cG
>> U+
>>>
>> DQogICAgPFR5cGU 
>> +aHR0cDovL3NwZWNzLm9wZW5pZC5uZXQvdHgvMS4wPC9UeXBlPg0KICAgID
>> xV
>>>
>> Ukk 
>> +aHR0cHM6Ly9leGFtcGxlLmNvbS9zZXJ2ZXI8L1VSST4NCiAgPC9TZXJ2aWNlPg0KICA8 
>> U2
>> Vy
>>>
>> dmljZT4NCiAgICA8UHJvdmlkZXJJRD5odHRwczovL3N0cy5lcXVpZmF4LmNvbS8jMjAwO 
>> DEyMD
>> 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
>
>
>
> ---------------------------------------------------------------------
> 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
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iEYEARECAAYFAkl4ul0ACgkQrPgSa0qMrmGnbACgj5NJ9TI8hIlhQfYSBI5PKLaQ
xGwAn1JMgMb0LIndMrmM8WxF2DJIH7mm
=7Kjm
-----END PGP SIGNATURE-----


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