Subject: [scim] Base64 Encoding for Binary Attributes

From: Phil Hunt <[email-masked]>
Date: Mon, 2 Mar 2015 11:07:12 -0800

I was looking through the schema document and cleaning up the data type characteristics (as discussed previously), I notice that the reference to XML-Schema is to the October 2004 one and not the 2012 XML Schema.  The IETF will likely require us to reference the current spec, so I should probably update the reference.

Looking at the binary attribute representation, I am wondering if we should change this to the current IETF specification which is: RFC4648 rather than reference XML-Schema 3.2.16 (of the 2004 schema spec).

Do we want to further clarify that the encoding be: base64url?   Not a javascript expert, but wondering if we need to use url safe encoding? This may result in a normative clarification for some.

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Ian Glazer <[email-masked]>
Date: Mon, 2 Mar 2015 15:06:54 -0500

Would this be base64url "required" or "recommended"?

Would the encoding type be a declared attribute of the SP?

On Mon, Mar 2, 2015 at 2:07 PM, Phil Hunt <[email-masked]> wrote:

>
> I was looking through the schema document and cleaning up the data type
> characteristics (as discussed previously), I notice that the reference to
> XML-Schema is to the October 2004 one and not the 2012 XML Schema.  The
> IETF will likely require us to reference the current spec, so I should
> probably update the reference.
>
> Looking at the binary attribute representation, I am wondering if we
> should change this to the current IETF specification which is: RFC4648
> rather than reference XML-Schema 3.2.16 (of the 2004 schema spec).
>
> Do we want to further clarify that the encoding be: base64url?   Not a
> javascript expert, but wondering if we need to use url safe encoding? This
> may result in a normative clarification for some.
>
> Phil
>
> @independentid
> www.independentid.com
> [email-masked]
>
>
> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim
>
>

-- 
Ian Glazer
Senior Director, Identity
+1 202 255 3166
@iglazer <https://twitter.com/iglazer>

---

From: Phil Hunt <[email-masked]>
Date: Mon, 2 Mar 2015 12:25:33 -0800

I think it should be one form. 

My recommendation would be base64url for max utility. Especially if we start defining schema related to JWT keys (JWK) from OAuth and JOSE. 

Phil

> On Mar 2, 2015, at 12:06, Ian Glazer <[email-masked]> wrote:
> 
> @iglazer

---

From: Phil Hunt <[email-masked]>
Date: Mon, 2 Mar 2015 15:50:12 -0800

All,

Michael has reminded me that x509Certificate is DER encoded binary which is in conflict with our current binary definition.

I recommend changing the definition of Binary FROM:
2.2.6.  Binary

   Arbitrary binary data.  The attribute value MUST be encoded as a base
   64 encoding as specified in Section 3.2.16 [XML-Schema].  A binary is
   case-exact and has no uniqueness.

   Values represented in JSON MUST conform to the XML constraints above
   and are represented as a JSON String per Section 2.7 [RFC7159].
TO:
2.2.6.  Binary

   Arbitrary binary data.  The attribute value MUST be encoded in Base
   64 encoding as specified in Section 4 [RFC4648].  In cases where a
   URL-safe encoding is required, the attribute definition MAY specify
   Base 64 URL encoding MAY be used as per Section 5 [RFC4648].

   In JSON representation, the encoded values are represented as a JSON
   String per Section 7 [RFC7159].  A binary is case-exact and has no
   uniqueness.
Further, I would recommend changing x509certificates FROM:
   x509Certificates
      A list of certificates issued to the User.  Values are Binary
      (Section 2.2.6) and DER encoded x509.  This value has NO canonical
      types.
TO:
   x509Certificates
      A list of certificates issued to the User.  Values are binary
      (Section 2.2.6) and are Base 64 encoded x509 per Section 4
      [RFC4648].

Important:  This is a normative change as we are correcting the previous “DER” encoding to be base 64 encoding for consistency with the definition of binary and JSON compatibility.

If possible, please have comments to the list by 5PM Pacific tomorrow (Tuesday).  I would like to publish draft 17 of core-schema in order to be able to publish the changes to the API draft later in the week.  Note that the proposed changes for tomorrow include expanding section 8.7 to include schemas for fixed (non-resource) service provider schemas:  ServiceProviderConfig, ResourceType, Schema.

Cheers,

Phil

@independentid
www.independentid.com
[email-masked]

> On Mar 2, 2015, at 12:25 PM, Phil Hunt <[email-masked]> wrote:
> 
> On Mar 2, 2015, at 12:06, Ian Glazer <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> On Mon, Mar 2, 2015 at 2:07 PM, Phil Hunt <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> www.independentid.com <http://www.independentid.com/>[email-masked] <mailto:[email-masked]>
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/scim <https://www.ietf.org/mailman/listinfo/scim>
>> 
>> 
>> 
>> 
>> -- 
>> Ian Glazer
>> @iglazer <https://twitter.com/iglazer>_______________________________________________
> scim mailing list
> [email-masked]

---

From: Ian Glazer <[email-masked]>
Date: Tue, 3 Mar 2015 10:29:19 -0500

I am okay with this change

On Mon, Mar 2, 2015 at 6:50 PM, Phil Hunt <[email-masked]> wrote:

> All,
>
> Michael has reminded me that x509Certificate is DER encoded binary which
> is in conflict with our current binary definition.
>
>    Arbitrary binary data.  The attribute value MUST be encoded in* Base
>    Base 64 URL encoding MAY be used as per Section 5 [RFC4648]*.
>
>    *In JSON representation, the encoded values are represented as a JSON
>    uniqueness.*
>       (Section 2.2.6) and* are Base 64 encoded x509 per Section 4
>       [RFC4648].*
>
>
> *Important:  This is a normative change as we are correcting the previous
> “DER” encoding to be base 64 encoding for consistency with the definition
> of binary and JSON compatibility.*
>
> *If possible, please have comments to the list by 5PM Pacific tomorrow
> (Tuesday)*.  I would like to publish draft 17 of core-schema in order to
> be able to publish the changes to the API draft later in the week.  Note
> that the proposed changes for tomorrow include expanding section 8.7 to
> include schemas for fixed (non-resource) service provider schemas:
>  ServiceProviderConfig, ResourceType, Schema.
>
> Cheers,
>
> Phil
>
> @independentid
> www.independentid.com
> [email-masked]
>
> My recommendation would be base64url for max utility. Especially if we
> start defining schema related to JWT keys (JWK) from OAuth and JOSE.
>
> Phil
>

---

From: Kelly Grizzle <[email-masked]>
Date: Tue, 3 Mar 2015 15:53:00 +0000

I’m haven’t followed JWT/JWK, so don’t know all of the history.

However, based on reading RFC 4648, it seems that base64url is primarily used if the encoded data will appear in a URL or filename.  Given the fact that in SCIM base64 will always occur in request and response bodies, I don’t know that we need to worry about base64url.

On the other hand, if most identity-related standards are using base64url, it might make sense to go with this for consistency.

In either case, I agree that we should standardize on either base64 or base64url and not allow both.

--Kelly

From: scim [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Monday, March 02, 2015 2:26 PM
To: Ian Glazer
Cc: SCIM WG
Subject: Re: [scim] Base64 Encoding for Binary Attributes

Phil

On Mar 2, 2015, at 12:06, Ian Glazer <[email-masked]<mailto:[email-masked]>> wrote:
Would this be base64url "required" or "recommended"?

On Mon, Mar 2, 2015 at 2:07 PM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:

Phil

@independentid
www.independentid.com<http://www.independentid.com>
[email-masked]<mailto:[email-masked]>

_______________________________________________
scim mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/scim

--
Ian Glazer
Senior Director, Identity
+1 202 255 3166
@iglazer<https://twitter.com/iglazer>

---

From: Phil Hunt <[email-masked]>
Date: Tue, 3 Mar 2015 08:43:21 -0800

JWK is JSON web key. They are passable in urls.  

JWK is the new JSON equivalent of x509.

The good news is these are all just strings.  So no extra coding to support. But the client will need to know how it is encoded. I propose the attribute defn can do this sufficiently.  

Phil

> On Mar 3, 2015, at 07:53, Kelly Grizzle <[email-masked]> wrote:
>

---

From: Kelly Grizzle <[email-masked]>
Date: Tue, 3 Mar 2015 16:54:11 +0000

> I propose the attribute defn can do this sufficiently.

I’m not sure that I understand this.  Are you just saying that the binary data type will specify that base64url is always used?  Or are you saying that the attribute definitions in the schema will somehow indicate which encoding is used (either through a different type or just in the description)?

From: Phil Hunt [mailto:[email-masked]]
Sent: Tuesday, March 03, 2015 10:43 AM
To: Kelly Grizzle
Cc: Ian Glazer; SCIM WG
Subject: Re: [scim] Base64 Encoding for Binary Attributes

Phil

On Mar 3, 2015, at 07:53, Kelly Grizzle <[email-masked]<mailto:[email-masked]>> wrote:
I’m haven’t followed JWT/JWK, so don’t know all of the history.

--Kelly

Phil

Phil

@independentid

---

From: Phil Hunt <[email-masked]>
Date: Tue, 3 Mar 2015 09:18:15 -0800

No. Base64 is proposed as the default because we wouldn't pass by url. 

However some things we will want to store must be url encoded by their own specification such as json keys.  

We could make binary a complex type where encoding can be specified, but it only make sense if you expected the encoding to dynamically change. That isn't the case here.  Eg A JWK must always be base64url. 

AFAIK x509 would always be base64. 

Phil

> On Mar 3, 2015, at 08:54, Kelly Grizzle <[email-masked]> wrote:
>

---

From: Kelly Grizzle <[email-masked]>
Date: Tue, 3 Mar 2015 17:38:55 +0000

Ah … I understand what you’re saying now.  That makes sense to me.

So the type would be “binary” which would usually be base64, but could optionally be base64url if the attribute definition specifies this?

From: Phil Hunt [mailto:[email-masked]]
Sent: Tuesday, March 03, 2015 11:18 AM
To: Kelly Grizzle
Cc: Ian Glazer; SCIM WG
Subject: Re: [scim] Base64 Encoding for Binary Attributes

Phil

Phil

--Kelly

Phil

Phil

@independentid

---

From: Phil Hunt <[email-masked]>
Date: Tue, 3 Mar 2015 09:41:33 -0800

Yes. 😄

Phil

> On Mar 3, 2015, at 09:38, Kelly Grizzle <[email-masked]> wrote:
>

---

From: Erik Wahlström neXus <[email-masked]>
Date: Tue, 3 Mar 2015 19:23:14 +0000

I would prefer to keep DER in there. To ease interop.

x509Certificates
      A list of certificates issued to the User.  Values are binary
      (Section 2.2.6) and are DER encoded x509 certificates that's Base 64 encoded x509 per Section 4 [RFC4648].?

/ Erik

________________________________
From: scim <[email-masked]> on behalf of Phil Hunt <[email-masked]>
Sent: Tuesday, March 3, 2015 12:50 AM
To: Ian Glazer
Cc: SCIM WG
Subject: Re: [scim] Base64 Encoding for Binary Attributes

All,

2.2.6.  Binary

TO:

2.2.6.  Binary

   x509Certificates

TO:

   x509Certificates

Important:  This is a normative change as we are correcting the previous "DER" encoding to be base 64 encoding for consistency with the definition of binary and JSON compatibility.

Cheers,

Phil

@independentid

On Mar 2, 2015, at 12:25 PM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:

Phil

Phil

@independentid
www.independentid.com<http://www.independentid.com/>
[email-masked]<mailto:[email-masked]>

---

From: Phil Hunt <[email-masked]>
Date: Tue, 3 Mar 2015 11:45:37 -0800

Afaik der is not compatible with UTF8 as it is asn1.  Not sure. Can someone find a reference?

Phil

> On Mar 3, 2015, at 11:23, Erik Wahlström neXus <[email-masked]> wrote:
> 
>       (Section 2.2.6) and are DER encoded x509 certificates that's Base 64 encoded x509 per Section 4 [RFC4648].​
> 
> / Erik
> 
>

---

From: Anthony Nadalin <[email-masked]>
Date: Tue, 3 Mar 2015 20:12:49 +0000

I’m confused, why would we not just use what JOSE used for Binary Encoding ?

From: scim [mailto:[email-masked]] On Behalf Of Ian Glazer
Sent: Tuesday, March 3, 2015 7:29 AM
To: Phil Hunt
Cc: SCIM WG
Subject: Re: [scim] Base64 Encoding for Binary Attributes

On Mon, Mar 2, 2015 at 6:50 PM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:
All,

2.2.6.  Binary

2.2.6.  Binary

   uniqueness.

   x509Certificates

      types.
TO:

   x509Certificates

      [RFC4648].

Cheers,

Phil

@independentid

Phil

Phil

@independentid

+1 202 255 3166<tel:%2B1%20202%20255%203166>

---

From: "Morteza Ansari (moransar)" <[email-masked]>
Date: Wed, 4 Mar 2015 20:17:33 +0000

Wearing individual contributor hat: I think there is some confusion here on the x509Certificate attribute.  The definition for this attribute comes more or less directly from SCIM 1.1 spec. The idea is that certificates are stored as DER encoded using SCIM binary data type which is base64 encoded strings.  As such I don’t believe there is any issues with representing any type of certificate given DER encoding handles that fully and base64 encoding is only done for transferring the DER encoded certs over SCIM API. And given the attribute is plural, we can have many certificate values (each DER encoded and then base64 encoded).

As chair: Given the confusion, I certainly think we should as minimum adjust the text for this attribute to be more precise and clear about the intention.  Phil, can you propose some text for that clarification.  Also, given this definition does anyone think this is something that should be revisited?

Cheers,
Morteza

From: Anthony Nadalin <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, March 3, 2015 at 12:12 PM
To: Ian Glazer <[email-masked]<mailto:[email-masked]>>, Phil Hunt <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [scim] Base64 Encoding for Binary Attributes

2.2.6.  Binary

2.2.6.  Binary

   uniqueness.

   x509Certificates

      types.
TO:

   x509Certificates

      [RFC4648].

Cheers,

Phil

@independentid

Phil

Phil

@independentid

---

From: Anthony Nadalin <[email-masked]>
Date: Wed, 4 Mar 2015 20:20:06 +0000

We should just take the text from JWK on x5c or x5u

From: Morteza Ansari (moransar) [mailto:[email-masked]]
Sent: Wednesday, March 4, 2015 12:18 PM
To: Anthony Nadalin; Ian Glazer; Phil Hunt
Cc: SCIM WG
Subject: Re: [scim] Base64 Encoding for Binary Attributes

Wearing individual contributor hat: I think there is some confusion here on the x509Certificate attribute.  The definition for this attribute comes more or less directly from SCIM 1.1 spec. The idea is that certificates are stored as DER encoded using SCIM binary data type which is base64 encoded strings.  As such I don't believe there is any issues with representing any type of certificate given DER encoding handles that fully and base64 encoding is only done for transferring the DER encoded certs over SCIM API. And given the attribute is plural, we can have many certificate values (each DER encoded and then base64 encoded).

Cheers,
Morteza

I'm confused, why would we not just use what JOSE used for Binary Encoding ?

2.2.6.  Binary

2.2.6.  Binary

   uniqueness.

   x509Certificates

      types.
TO:

   x509Certificates

      [RFC4648].

Cheers,

Phil

@independentid

Phil

Phil

@independentid

---

From: "Morteza Ansari (moransar)" <[email-masked]>
Date: Wed, 4 Mar 2015 20:44:17 +0000

We certainly should take as much of it as possible from x5c in JWK.  The only part that might not apply to us is the array part given this attribute is multivalued which means the array is probably not needed.  I believe Phil is planning on reaching out to Mike Jones to confirm that.

Cheers,
Morteza

From: Anthony Nadalin <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, March 4, 2015 at 12:20 PM
To: Morteza Ansari <[email-masked]<mailto:[email-masked]>>, Ian Glazer <[email-masked]<mailto:[email-masked]>>, Phil Hunt <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [scim] Base64 Encoding for Binary Attributes

Cheers,
Morteza

2.2.6.  Binary

2.2.6.  Binary

   uniqueness.

   x509Certificates

      types.
TO:

   x509Certificates

      [RFC4648].

Cheers,

Phil

@independentid

Phil

Phil

@independentid

---

From: Phil Hunt <[email-masked]>
Date: Wed, 4 Mar 2015 12:57:21 -0800

The array in jwk x5c is an array representing a certificate chain. 

While the array in scim x509certificates is for multiple different certs representing a user. 

Mike...any reason why a certificate chain wasn't encoded directly at the DER encoding level?

For SCIM the worry is having an array that needs to contain arrays of certificate chains. 

Phil

> On Mar 4, 2015, at 12:44, Morteza Ansari (moransar) <[email-masked]> wrote:
> 
> From: Anthony Nadalin <[email-masked]>
> To: Morteza Ansari <[email-masked]>, Ian Glazer <[email-masked]>, Phil Hunt <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> From: Anthony Nadalin <[email-masked]>
> To: Ian Glazer <[email-masked]>, Phil Hunt <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>