OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

provision message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: [provision] What exactly do we mean by provisioning?


Title: RE: [provision] What exactly do we mean by provisioning?

  
> I like the idea of using tying "Identity" to "Provisioning"
> to describe what we are doing, but we have to be careful. We
> should not give the impressiong that the focus is to manage
> the identity itself.

I think we are. I believe identity is the sum of the attributes of the entity being identified. If I say you are a Gold Customer, I am managing your identity. Perhaps you meant we are not managing the Proof of Identity (Authentication inputs). However, I suspect that some people will want to ship this stuff around as well, although we should certainly avoid the unnecessary duplication of existing protocols for Authentication, Certificate Management, etc.

Hal

>Unfortunately, "Identity-Related
> Provisioning" is likely to cause that exact sort of
> confusion. The best term I can come up with is:
>     Resource to Identity Provisioning
> Which is descriptive but probably to long.
> I think we should stick with "Provisioning" for now and tie
> it to a definition of what it means.
> Jeff B.
> Darran Rolls wrote:
> I think what we are trying to get to here is wording that
> includes the ability to pass requests to a provisioning
> service that itself may be driving a "non-digital"
> provisioning process.To explain...
> abcProvisioing Inc provides a PSML compliant provisioning
> server.Behind it's PSML interface is a cross-system
> provisioning server, managing a range of directories,
> applications and servers PLUS (to use a simple understandable
> example) a non-digital cell-phone request "resource".The
> former are the well understood resources -
> account/security/attribute oriented things that we all seem
> to agree are in scope. The latter is really just an
> encapsulated workflow process that when provisioned to
> results in a managed request/response protocol to some down
> stream service component (deliberately vague and clearly out
> of scope for PSML). The abcProvisioning service may even
> group all these resource elements into an arbitrary
> collection suitable or useful for general management purposes
> or as part of some internal role based allocation mechanism. 
> This makes most sense when you consider provisioning a new
> user at abcSupplyCo.The new guy needs a directory account, a
> couple of UNIX accounts, an NT and exchange account, some
> entries in some RDBMS tables somewhere for some C/S apps AND
> a cell phone request sent to cracklyWirelessCo via a simple
> secure email interface.
> The user of the PSML service goes through a trust
> establishment, service query and required attributes exchange
> with the provisioning service.It then send off all the
> required identity and security attributes along with an
> <cell_phone plan='gold' phone='simple' services='all'/> element. 
> The definition of the required data to provision these things
> would be the responsibility of the provisioning service to
> "define" and ship back to the requester in some form of query
> vocabulary.So I guess what I'm saying is:
> 1 - The attributes of the "provisioned to" thing could be
> dynamically queried so are therefore less critical to scope
> 2 - However, I agree we need to scope the term to better
> facilitate understanding of the work at hand
> 3 - I'd rather avoid eProvisioning (a bit close to some
> existing products in this space)
> 4 - How about eService Provisioning?
> 5 - We should deliberately run a loose boundary around the
> "provision to" list/terms, whilst at the same time avoiding
> Edwards sea boiling.
> Darran Rolls
>
> Waveset Technologies
> MSIM  drolls_waveset@hotmail.com
> AIM    drollswaveset
> YIM    drolls_waveset
> http://www.waveset.com/
> drolls@waveset.com
>
> -----Original Message-----
>
> From: Truitt, Edward D. (OSED) [mailto:OSED@chevrontexaco.com]
> Sent: Tuesday, November 27, 2001 4:56 PM
> To: 'provision@lists.oasis-open.org'
> Subject: RE: [provision] What exactly do we mean by provisioning?
> I don't have a problem with trying to narrow the scope.
> However, I think we need to think beyond people. For example,
> I can see other types of objects (e.g. workstations,
> applications) being "provisioned" (granted access to IT
> resources & services) in the future, especially if we are
> using provisioning as a means of managing RBAC. This is a
> significant point that has been made by several NAC members
> over the past year - that we should seek to avoid being
> "person-centric" when defining requirements and designing solutions.
> Therefore, I would suggest that Hal's first idea is the
> "best" choice here. Think of all the types of objects
> (entries) that we might want to store in directories and
> manage access to resources and services for (I can certainly
> accept an IT focus for now, lest we end up in an
> ocean-boiling exercise), and focus on how to encode the
> schema for these so that the various provisioning systems and
> the provisioned (target) systems can easily communicate
> amongst each other.
> If "eProvisioning" isn't owned by somebody, that might be the
> best term to use. Otherwise, I would prefer something like
> "IT Services Provisioning" or "ProvisionIT" which the TC
> could define as it wishes.
> -Ed Truitt
> -----Original Message-----
> From: Hal Lockhart [mailto:hal.lockhart@entegrity.com]
> Sent: Tuesday, November 27, 2001 2:51 PM
> To: provision@lists.oasis-open.org
> Subject: [provision] What exactly do we mean by provisioning?
>
> It is time to be more precise about the charter of this
> group. In particular I am concerned about the meaning of the
> unmodified word "Provisioning" which I believe may mean
> different things to different people.
> [snipped for brevity]
> The second is broader than the first, but both are much
> narrower than the meaning above in that they revolve around
> the concept of "user" and therefore identity. For example, if
> a web hosting company sets up a virtual server for a new
> customer, this would be included in the broader meaning, but
> not the narower one. Thumbing through the materials from the
> XRPM meeting, it seems to me that most of the people present
> had in mind the narrower meaning. In particular, Phil called
> for a standardized way to encode the identity schema.
> The ADPr site offers this: "eProvisioning refers to
> automating the process of systematically providing resources
> and services, according to business requirements." However
> all the examples they cite revolve around a person.
> So I guess the choice boils do to pretty much two ideas:
> 1. Eveything you do in responce to an order for service.
> 2. Everything you do to provide service for a person.
> My position is that I don't feel strongly about what scope is
> chosen as long as it is made explicit. I offer the following
> observations:
> 1. We need to limit scope in some way if we hope to
> accomplish anything.
> 2. If the scope is limited to "identity-related"
> considerations, we might want to qualify the term
> provisioning with an adjective, since there are a large
> number of organizations that use the term in a broader sense
> and are likely to misinterpret our use. Possibilities
> include: User Provisioning, User Service Provisioning,
> Identity-related Provisioning.
> Hal
> --
> Jeff bohren
> Product Architect
> OpenNetwork Techologies
> jbohren@opennetwork.com
> (727) 561-9500x219
>  
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC