MetadataProvider and update

[Brent Putman]

On 5/11/17 4:55 PM, Cantor, Scott wrote:
>
> Probably, yes, that's an option. It's a bit messy because of the need to encode all the filenames.

Agreed it's a little messy, but not technically hard to automate.  The
thing I have always disliked about the hashed approach is that it's
one-way (see below).


> Hex encoded (base64 doesn't make for good filenames), 

Yes, base64 classic doesn't work.  However, recently whilst re-reading
the JOSE/JWT/OAuth2/OIDC specs, I was reminded of the alternate
base64url encoding defined in RFC 4648 [1] that is used everywhere in
those specs.  In the RFC it's explicitly mentioned as intended to be
filesystem-safe as well as URL-safe (for the latter removing the need
for a URL encoding).  That encoding replaces the pesky and problematic
'/', and '+' characters with the more filename-friendly '-' and '_', and
makes '=' padding optional (you can compute it based on the encoded
length).  So it has occurred to me that base64url encoding for these
filename cases might actually work fine.  And it also makes the
filenames reversible from the filename alone (as opposed to having to
peek inside the XML and parse out the entityID).


> and I don't recall but I think it's lower case, and easy enough to try and see.

Fwiw I think in OpenSAML/IdP it defaults to lower-case hex.


[1] https://tools.ietf.org/html/rfc4648#page-7
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20170511/60e7d94f/attachment.html>