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
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/blueroofmusichttp://sites.google.com/site/highnorthinc
mailto: blueroofmusic at gmail.com
Winter 579 Park Place Saline, MI 48176 734-944-0094
Summer PO Box 221 Grand Marais, MI 49839 906-494-2434
On Mon, Jun 16, 2014 at 11:19 AM, Michael Sweet <msweet at apple.com> wrote:
> Ira,
>> On Jun 16, 2014, at 11:02 AM, Ira McDonald <blueroofmusic at gmail.com>
> 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.
>>> 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
> concatenation to support large credentials (X.509 certificates, etc.).
>>> That is indeed a simple solution, but let's not make it an opaque blob.
>> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>>-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20140616/7d8a7cce/attachment.html>