DataSealer and encoding (and location)

[Rod Widdowson]

Partially answering myself...  There is, of course, one reason to keep using
Base32 - so that customers can roll an upgrade around a cluster without any
downtime.

I suspect that again this is for Scott to make the call on, since he runs
that sort of cluster.  It would be nice not to bring forward more legacy
code, but it would also be nice to be able to roll people forward from V2 to
V3.

/R 

> -----Original Message-----
> From: dev-bounces at shibboleth.net [mailto:dev-bounces at shibboleth.net]
> On Behalf Of Rod Widdowson
> Sent: 05 March 2013 12:41
> To: Shib Dev
> Subject: DataSealer and encoding (and location)
> 
> (Mostly for Scott),
> 
> As part of the CryptoTransient AttributeDefinition/PrincipalConnector work
I
> am bringing the (old) DataSealer over from 2.0.
> 
> The "port" is relatively straight forward, although testing might be a
> challenge.  But I see that it is encoding the blob using Base32 (which has
> its own implementation).
> 
> This stuff is going to end up as a NameID, so my question is whether this
> has to be Base32 (which would require me to port the encoder over as well)
> or can we use Base64? Are their SAML implementations out there that mess
> with the case of the NameID? Or is this just history>
> 
> I'll note that other attribute definitions which go through a similar
> manipulation (ComputedID) are encoded using Base64.
> 
> There is another question as to where this implementation should live.
For
> now it can live in idp-attribute-resolver-impl because that is the only
> place it will be used, I'll garnish it with TODOs so that we revisit the
> location.  However it feels as though this should really go into a util
> directory somewhere.
> 
> /Rod
> 
> 
> --
> To unsubscribe from this list send an email to dev-
> unsubscribe at shibboleth.net