Subject: Re: Java GSS bindings (fwd)

From: Michael Smith <[email-masked]>
Date: Fri, 05 Feb 1999 22:59:00 -0500

At 03:26 PM 2/5/99 -0800, Mike Eisler <[email-masked]> wrote:
>In your proposal, I'm curious if it is possible to write a java program that
>doesn't have any explicit references in the source code to the GSS-API
>mechanism that implements the interface? 

You seem to be laboring under the same -- perhaps understandable 
-- misundertanding as Mayank. "Implementation" does not equal 
"mechanism" -- in C, or Java, or perl or whatever. 

The idea was that an _implementation_ (developed with a 
particular institutional or application setting in mind) would 
incorporate the _mechanisms_ (note the plural) appropriate to that 
setting. And yes, the whole idea was to relieve the application 
programmer of the burden of knowing anything about mechanisms -- 
which was also the GSS-API goal, right from the beginning, wasn't it?
The short answer to your question, if this isn't clear, is "yes".
Indeed, I would say that that was the overriding motive in defining 
the API as interfaces rather than concrete classes.  

>Stated another way, can I write
>program such that it accepts as input a mechanism OID, etc. and then creates a
>context with that mechanism?

Assuming that the the mechanism referred to by that OID is available 
locally. Which is, of course, not a standards question. -- But again, in
principle, the answer is "yes".

>FYI, Mayank protoyped the specification and it includes an SPI.

Very glad to hear it; but I haven't yet seen that, or a reference to it.
Is this an Internet-Draft? If so, send a URL, and I'll read it with 
great and highly sympathetic interest.

>> If Sun wants to define and
>> build the concrete "veneer" classes implementing GSS, and include them
>> in the core classes of Java, say, and define the SPI while they're at
>> it, this would be fine with me. 
>
>Interesting set of requirements.  Perhaps I haven't subscribed to this alias
>long enough, but I don't recall someone ever stating that as long as John
>Wray's employer defined an SPI, draft-ietf-cat-gssv2-cbind-XX.txt would be
>fine with him. 

Java is a proprietary product. This does not prevent me 
from being a great fan of Java -- otherwise, why would I be burning all 
these cycles on a Java binding?  But at the same time, we all know that 
when the owners of Java want to do X or Y with it, then X or Y is likely to
happen. If the owners of Java, as such, want a set of concrete classes 
and an "SPI", then the rest of us will have to accommodate that, and the 
best that users of Java (like me) can hope to do is offer constructive 
suggestions. What we users want to know is simply this: does the presence
of ".sun.com" in your e-mail address mean that you're speaking for the 
owners of Java; or are you speaking only for yourselves? We can handle 
it either way, but surely you can understand why we would be interested 
in knowing which is the case? For one thing, we don't want to waste 
our time pissing into the wind and defining something dead contrary to what 
the owners of Java want to do with it. On the other hand, if it's just your 
opinion versus ours, on a level playing field, well that's another matter. 
Don't take this as some kind of an attack -- I just want to know, so to 
speak, who I'm talking to. 

>Why is it that we assume the can opener for C and not for Java?

Exactly; but we _haven't_ assumed it for C, because nobody has yet 
stepped up and defined a provider interface, either language-independent
or language-bound. Being a standards-oriented guy, I'd prefer to see it 
defined language-independent before language-bound, for reasons that 
I'm sure you'll understand. The "veneer" approach is as applicable 
to C as it is to Java.  On the other hand, if the work in the Java 
context leads to the definition of a broader language-independent 
definition -- well, that would unquestionably be a Good Thing, wouldn't 
it? 

--Michael Smith
  [email-masked]

==========================================================================
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email-masked]

---

From: Mike Eisler <[email-masked]>
Date: Fri, 5 Feb 1999 21:18:41 -0800 (PST)

> "mechanism" -- in C, or Java, or perl or whatever. 

I don't understand the above sentence. Anyway ...

> The short answer to your question, if this isn't clear, is "yes".
							^^^^^^^^^^

> >program such that it accepts as input a mechanism OID, etc. and then
> creates a >context with that mechanism?
> 
			^^^^^^^^

Good and Good.

What would one have to do to the existing internet-draft to use your proposal?

> ...
 
> speak, who I'm talking to. 

My opinion versus yours is very much a level playing field, because I can't
wave my wand and add GSS-API to the Java specification. Once this WG agrees to
a specification, it's up to the powers-that-be in Java Software to incorporate
this specification or not. 

> Exactly; but we _haven't_ assumed it for C, because nobody has yet
							^^^^ 
> stepped up and defined a provider interface, either language-independent

Solaris7's C-bindings GSS-API has an SPI, only it's not documented. There's
some semblance of an SPI in the MIT Kerberos 1.0 implementation of the
C-bindings GSS-API. Microsoft has its Security Service Provider Interface,
which by its name implies an SPI for a C-bindings GSS-API. 

I can't offer up the the Java or C SPI that my employer has because it's not
mine to offer up. 

If the WG decides to define an SPI, I want to understand the SPI's impact to
the consumer of the GSS-API, because ease of programming should be an
overriding concern if we want applications to use Java GSS. Hence my earlier
question ("What would one have to do ...?").

	-mre