Subject: [IPP] Fwd: IPP Scan operational attribute

From: Ira McDonald <[email-masked]>
Date: Sun, 15 Jun 2014 18:21:05 -0400

[forwarding to IPP WG list for our Scan discussion on Monday 16 June]

---------- Forwarded message ----------
From: Ira McDonald <[email-masked]>
Date: Fri, Jun 13, 2014 at 5:22 PM
Subject: Re: IPP Scan operational attribute
To: "Zehler, Peter" <[email-masked]>, Ira McDonald <
[email-masked]>

Hi Pete,

So here's a fragment of IPP stuff for the operation attribute
that can be sparse (i.e., does NOT have to be parallel to the
"destinations" array)

destination-acceses (1setOf destination-access)

destination-access (collection)
- member attributes below

destination-numbers (1setOf Integer)
- required to supply in every row
- ordinals of rows in "destinations" Job attribute
- out-of-range ordinal is a fatal Job submission error

destination-user-name (name(MAX))
- optional to supply in a given row
- for username/password authentication

destination-auth-type (type3 keyword | name)
- required to supply in every row
 - taken from Joe's list with extensions
- type3 to allow ease-of-extensions (w/out new IPP spec)

destination-auth-data (1setOf octetString(MAX))
- required to supply in every row
- binary or UTF-8 text
- multiple values are concatenated
- solves the large attribute problem w/out a new datatype

WDYT?

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: [email-masked]
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434

On Fri, Jun 13, 2014 at 12:24 PM, Zehler, Peter <[email-masked]>
wrote:

>  Ira,
>
>
>
> As you know I need to add an operational attribute to IPP Scan that
> contains the information necessary for a Scan Service to store a document
> at a specified location.  I imagine it would contain items like access
> tokens or even (yuk) username/password.  The operational attribute will be
> a parallel collection to IPP Scan’s destinations collection.  In the
> Imaging Device Security Identification, Authentication and Authorization
> specification the UserIdentificationType looks close to what I need.  On
> the wire I do not think I need the UserUuid and I’ll need a
> username/password.
>
>
>
> Any idea what I should be using and where I might obtain the detailed
> definition?
>
>
>
> Pete
>
>
>
>
>
> Peter Zehler
>
> Email: [email-masked]
> Office: +1 (585) 265-8755
>
> Mobile: +1 (585) 329-9508
> FAX: +1 (585) 265-7441
> US Mail: Peter Zehler
> Palo Alto Research Center Incorporated
> 800 Phillips Rd.
> M/S 128-25E
> Webster NY, 14580-9701
>
>
>
_______________________________________________
ipp mailing list
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: Michael Sweet <[email-masked]>
Date: Mon, 16 Jun 2014 07:45:37 -0400

Ira,

I'm not a big fan of this proposal - I'd prefer the parallel 1setOf that we typically use in IPP rather than invent a sparse syntax, particularly when the most common use case is a single destination (and the second most common is probably a list of email recipients that won't need this...)

Also, if we want to generalize this in the future, perhaps prefix the member attributes with "access-" instead of "destination-", with the operation attribute being "destination-accesses (1setOf collection)".  That would make it:

    Operation Attributes:

    destination-accesses (1setOf collection)
        access-data (1setOf octetString(MAX))
        access-type (type3 keyword | name)
        access-user-name (name(MAX))

    Printer Description Attributes:

    access-type-supported (1setOf type3 keyword | name)
    destination-accesses-supported (1setOf type2 keyword)
        (required values 'access-data', 'access-type', and 'access-user-type' if supported)

For the access-data member attribute, I wouldn't hardcode it to be concatenation of values, since there are auth methods that require multiple "passwords", but rather define it for each access-type value.

....

(Future for Print-URI/Send-URI)

    Operation Attribute:

    document-access (collection)

    Printer Description Attribures:

    document-access-supported (1setOf type2 keyword)
        (required values 'access-data', 'access-type', and 'access-user-type' if supported)

On Jun 15, 2014, at 6:21 PM, Ira McDonald <[email-masked]> wrote:

> To: "Zehler, Peter" <[email-masked]>, Ira McDonald <[email-masked]>
> 
> 
> Hi Pete,
> 
> On Fri, Jun 13, 2014 at 12:24 PM, Zehler, Peter <[email-masked]> wrote:
> Ira,
> 
>  
> 
> As you know I need to add an operational attribute to IPP Scan that contains the information necessary for a Scan Service to store a document at a specified location.  I imagine it would contain items like access tokens or even (yuk) username/password.  The operational attribute will be a parallel collection to IPP Scan’s destinations collection.  In the Imaging Device Security Identification, Authentication and Authorization specification the UserIdentificationType looks close to what I need.  On the wire I do not think I need the UserUuid and I’ll need a username/password.
> 
>  
> 
> Any idea what I should be using and where I might obtain the detailed definition?
> 
>  
> 
> Pete
> 
>  
> 
>  
> 
> Peter Zehler
> 

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Ira McDonald <[email-masked]>
Date: Mon, 16 Jun 2014 11:02:50 -0400

Hi Mike,

The reason for some sparse syntax was to support Pete's use case (over the
phone)
of wanting two or more credentials for the *same* destination (i.e.,
multi-factor auth is
in use).  This is a critically important real-world use case.

With the straight parallel 1setOf approach, there has to be a nested
collection to hold
the auth-type, auth-data, etc. for each credential for one destination -
ugly and fragile.

Pete and I particularly liked the use of the simple (1setOf
octetString(MAX)) with auto
concatenation to support large credentials (X.509 certificates, etc.).

Cheers,
- Ira

On Mon, Jun 16, 2014 at 7:45 AM, Michael Sweet <[email-masked]> wrote:

> Ira,
>
> I'm not a big fan of this proposal - I'd prefer the parallel 1setOf that
> we typically use in IPP rather than invent a sparse syntax, particularly
> when the most common use case is a single destination (and the second most
> common is probably a list of email recipients that won't need this...)
>
> Also, if we want to generalize this in the future, perhaps prefix the
> member attributes with "access-" instead of "destination-", with the
> operation attribute being "destination-accesses (1setOf collection)".  That
> would make it:
>
>     Operation Attributes:
>
> For the access-data member attribute, I wouldn't hardcode it to be
> concatenation of values, since there are auth methods that require multiple
> "passwords", but rather define it for each access-type value.
>
> ....
>

---

From: Michael Sweet <[email-masked]>
Date: Mon, 16 Jun 2014 11:19:36 -0400

Ira,

On Jun 16, 2014, at 11:02 AM, Ira McDonald <[email-masked]> wrote:
> Hi Mike,
> 
> The reason for some sparse syntax was to support Pete's use case (over the phone)
> of wanting two or more credentials for the *same* destination (i.e., multi-factor auth is

Then we need to define it and its requirements.

> With the straight parallel 1setOf approach, there has to be a nested collection to hold
> the auth-type, auth-data, etc. for each credential for one destination - ugly and fragile.

If the auth type defines multiple credentials then those can be provided via separate data values in the 1setOf, or using type-specific member attributes.  In short, we need to define what the attributes contain, not provide a BLOB holder that will become an interoperability nightmare.

> Pete and I particularly liked the use of the simple (1setOf octetString(MAX)) with auto

That is indeed a simple solution, but let's not make it an opaque blob.

---

From: "Zehler, Peter" <[email-masked]>
Date: Mon, 16 Jun 2014 15:23:33 +0000

Sounds like I'll need to call into today's IPP meeting to see how this will be resolved.

Peter Zehler

[parc]
Email: [email-masked]<mailto:[email-masked]>
Office: +1 (585) 265-8755
Mobile: +1 (585) 329-9508
FAX: +1 (585) 265-7441
US Mail: Peter Zehler
Palo Alto Research Center Incorporated
800 Phillips Rd.
M/S 128-25E
Webster NY, 14580-9701

From: Michael Sweet [mailto:[email-masked]]
Sent: Monday, June 16, 2014 11:20 AM
To: Ira McDonald
Cc: [email-masked]; Zehler, Peter
Subject: Re: [IPP] Fwd: IPP Scan operational attribute

Ira,

On Jun 16, 2014, at 11:02 AM, Ira McDonald <[email-masked]<mailto:[email-masked]>> wrote:
Hi Mike,
The reason for some sparse syntax was to support Pete's use case (over the phone)
of wanting two or more credentials for the *same* destination (i.e., multi-factor auth is
in use).  This is a critically important real-world use case.

---

From: Ira McDonald <[email-masked]>
Date: Mon, 16 Jun 2014 11:24:50 -0400

Hi Mike,

Agreed.

It shouldn't be an opaque blob - the "access-type" should be sufficiently
fine-grained
to allow explicit multi-factor scenarios.

And Pete and I want to state that binary data MUST be sent as straight
"octetString"
and and text data (e.g., password) MUST be sent as UTF-8 (with no trailing
'\0').

The only downside (potentially pretty large for explicit multi-factor
"access-type"
values is rapid loss of interoperability when vendors roll their own name
values
for combinations we didn't anticipate.

Cheers,
- Ira

On Mon, Jun 16, 2014 at 11:19 AM, Michael Sweet <[email-masked]> wrote:

> If the auth type defines multiple credentials then those can be provided
> via separate data values in the 1setOf, or using type-specific member
> attributes.  In short, we need to define what the attributes contain, not
> provide a BLOB holder that will become an interoperability nightmare.
>

---

From: Michael Sweet <[email-masked]>
Date: Mon, 16 Jun 2014 20:33:20 -0400

Based on discussions in the conference call, here is a summary of the proposed additions to IPP Scan:

8.1.1 destination-accesses (1setOf collection | no-value)

The "destination-accesses" operation attribute allows the Client to provide authentication information for each of the "destination-uris" values. If provided, this attribute MUST have the same cardinality (have the same number of values) as the "destinations-uris" Job Template attribute. The ith value of the "destination-accesses" attribute corresponds to the ith value of the "destination-uris" attribute.

Each collection value contains zero of more member attribute which provide the authentication information required for the corresponding destination. A Client MAY also provide the no-value out-of-band value for a given destination to specify that no authentication information is supplied.

Printers specify which member attributes are supported using the "destination-accesses-supported" Printer attribute (section 8.4.1).  Printers specify which member attributes are required for a given destination in the "destination-mandatory-access-attributes" member attribute (section 8.4.2.7) of the "destination-uri-ready" Printer attribute (section 8.4.2).

8.1.1.1 access-oauth-token (1setOf octetString(MAX))

The "access-oauth-token" member attribute provides a Base64-encoded OAuth Access Token as defined in The OAuth 2.0 Authorization Framework [RFC6749]. When the size of the access token exceeds 1023 octets (the maximum size of an octetString value), the Client separates the token into multiple octetString values and sends the result as an ordered set to the Printer. The Printer reassembles each octetString to produce the complete access token value to be used with the destination.

Printers that support this attribute MUST list 'access-oauth-token' in the "destination-accesses-supported" Printer attribute (section 8.4.1).

8.1.1.2 access-password (text(MAX))

The "access-password" member attribute provides a password string, typically for HTTP Basic or Digest authentication [RFC2617]. Clients MUST provide the password using the UTF-8 encoding [STD63] in Unicode Normalization Form C as required for Network Unicode [RFC5198]. Printers MUST convert the password, as needed, to whatever encoding is required by the destination URI.

Printers that support this attribute MUST list 'access-password' in the "destination-accesses-supported" Printer attribute (section 8.4.1).

8.1.1.3 access-pin (text(MAX))

The "access-pin" member attribute provides a Personal Identification Number string. Clients MUST restrict the characters to the US ASCII digits '0' (code 48) through '9' (code 57) and Printers MUST reject values containing characters other than the digits '0' through '9'.

Printers that support this attribute MUST list 'access-pin' in the "destination-accesses-supported" Printer attribute (section 8.4.1).

8.1.1.4 access-user-name (text(MAX))

The "access-user-name" member attribute provides a user name string, typically for HTTP Basic or Digest authentication [RFC2617]. Clients MUST provide the user name using the UTF-8 encoding [STD63] in Unicode Normalization Form C as required for Network Unicode [RFC5198]. Printers MUST convert the user name, as needed, to whatever encoding is required by the destination URI.

Printers that support this attribute MUST list 'access-user-name' in the "destination-accesses-supported" Printer attribute (section 8.4.1).

[Editor's note: I am really not happy with the following, and would be happy to punt X.509 certificate passing for now since we don't have a good plan for management of private keys associated with x.509 certs...]

8.1.1.5 access-x509-certificate (1setOf octetString(MAX))

The "access-x509-certificate" member attribute provides a PEM-encoded X.509 certificate identifying the User or Client that is making the request.  When the size of the certificate exceeds 1023 octets (the maximum size of an octetString value), the Client separates the certificate into multiple octetString values and sends the result as an ordered set to the Printer. The Printer reassembles each octetString to produce the complete X.509 certificate to be used with the destination.

Printers that support this attribute MUST list 'access-x509-certificate' in the "destination-accesses-supported" Printer attribute (section 8.4.1) and MUST provide a method for loading the corresponding private key that is used for authenticating the holder of the X.509 certificate.

8.4.1  destination-accesses-supported (1setOf type2 keyword)

The "destination-accesses-supported" Printer attribute lists the supported member attributes of the "destination-accesses" operation attribute (section 8.1.1).  This attribute MUST be supported if the "destination-accesses" attribute is supported.

8.4.2.7 destination-mandatory-access-attributes (1setOf type2 keyword)

The "destination-mandatory-access-atributes" member attribute lists the member attributes that MUST be supplied in a Job Creation request when using this destination.

... plus the corresponding registrations in section 14 and normative references in section 15.1 (add RFC2617 and RFC6749)

On Jun 16, 2014, at 11:24 AM, Ira McDonald <[email-masked]> wrote:

> Hi Mike,
> 
> Agreed.
> 
> It shouldn't be an opaque blob - the "access-type" should be sufficiently fine-grained
> And Pete and I want to state that binary data MUST be sent as straight "octetString"  
> and and text data (e.g., password) MUST be sent as UTF-8 (with no trailing '\0').
> 
> The only downside (potentially pretty large for explicit multi-factor "access-type"
> values is rapid loss of interoperability when vendors roll their own name values